Четыре типажа программистов

Привет.
Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.

Читать дальше →

Нотация О-большое и сложность социальных взаимодействий

Если вам приходилось сидеть на невыносимо скучном совещании, где два человека обсуждают проблему, а все остальные являются зрителями, вы готовы принять идею о том, что такой способ взаимодействия не эффективен. Возможно, вы также задумывались об альтернативах. Ошибка организаторов встречи была в том, что они выбрали форму взаимодействия не соответствующую задаче, и, тем самым, обрекли большое количество людей на потерю времени.

Некоторое время назад, я понял, что к оценке сложности социальных взаимодействий, можно применять те же подходы, что и к оценке сложности алгоритмов – а значит можно увидеть их плюсы, минусы и области применения. Ниже краткий список наиболее частых вариантов, с которыми я имел дело.

О(n2): Совещание равноправных участников. n человек обсуждают вопрос, причем для достижения взаимопонимания, каждому участнику нужно пообщаться с каждым. Всего будет осуществлено n*(n-1)/2 социальных взаимодействий (эквивалентно задаче подсчета числа рукопожатий в группе из n человек), т.е сложность алгоритма О(n2). Казалось бы, за счет того, что общение одновременно могут осуществлять n/2 пар людей, оценка по времени – О(n), однако на реальных совещаниях в один момент времени говорит только один человек, поэтому оценка для худшего случая — О(n2). Если время взаимодействия – 5 минут и для достижения полного взаимопонимания в группе требуется две итерации, то совещание трех человек продлиться 30 минут, четырех – час, пятерым потребуется 1 час 40 минут для нахождения общего решения (что подозрительно похоже на правду). Если же число итераций зависит от числа участников, мы получаем еще более печальные оценки.

Но не все так плохо! Читать дальше →

О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 3

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

Во вступительной части была упомянута группа участников проекта, для которой мы так же обещали облегчить жизнь и обеспечить условия для эффективного использования требований – это менеджеры проекта. Что получают эти глубокоуважаемые люди при выборе предлагаемого в статье подхода?

Планируя работы по таким детальным спецификациям, еще на ранних стадиях, можно с высокой точностью определить ресурсы и сроки, необходимые для их реализации. Время, которое необходимо затратить на создание Таблицы, Формы, Функции, Отчета и т.д. можно просчитать на примере одного проекта и в дальнейшем использовать эти данные как эталонные. А в наших спецификациях, как раз и перечислены все таблицы, формы, процедуры и т.д. и сосчитать их количество не составляет труда.

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человеко\днях или человеко\часах (как Вам удобнее) по подсистемам и проекту в целом.
Читать дальше →

[Из песочницы] Об омолаживании вебсайта — критерии принятия решения

Ваша фирма десять лет назад вложила в разработку сайта существенные средства, и худо-бедно за эти годы сайт их отбил. Это выразилось как в новых клиентах, пришедших через сайт, так и в возможности оперативно информировать существующих клиентов о ваших продуктах и услугах.

Но, как любая современная технология, технология производства вебсайтов быстро развивается. Ваши клиенты больше не сидят за компьютерами, они стали путешествовать с планшетами и смотреть сайты на экранах смартфонов. Чтобы приспособиться к новым привычкам ваших клиентов, старый сайт нужно омолодить. А может и не надо?
Читать дальше →

Как управлять разработкой продукта из-за границы: 3 совета руководителям

Мы работаем над развитием платформы для email-маркетинга SendPulse. Сейчас у нас распределенная команда, разбросанная по нескольким странам. Мы поделимся своим опытом удаленного управления разработкой сложного продукта и дадим несколько практических советов. Коммуникации нужно регламентировать Наша команда разработки находится в Чернигове,Запись Как управлять разработкой продукта из-за границы: 3 совета руководителям впервые появилась
AIN.UA