?

Log in

No account? Create an account

Previous Entry | Next Entry

Dead Man March, circa 21 century

Замечали ли вы, что хорошие высоко-продуктивные программистские команды довольно регулярно находятся в состоянии аврала? Каждое окончание проекта, каждая мало-мальски важная дедлайн сопровождается долгими вечерами и рабочими выходными? Почему, спрашивается?

Тут многие не устоят перед соблазном тыкнуть пальцем в менеджеров. Мол, плохо оценивают время нужное на проект, или не следят за прогрессом достаточно тщательно чтобы всегда успеть переназначить финальную дату. Такое, конечно, тоже случается и нередко. Но дело не только в этом. Даже если взять идентичный проект сделанный в прошлом за, скажем, 4 недели, умножить время на 3 (не всегда есть такая возможность, но у меня бывали такие случаи) и назначить 12 недель, то, поверьте моему долгому опыту, дело все равно кончается ночами и выходными в офисе.

В чем же тут дело? У меня есть несколько (не взаимоисключающих) теорий на этот счет, но было бы интересно узнать ваше мнение (если вы, конечно, наблюдали описываемое явление).

Теория № 1: работа как воздух, заполняет все отведенное ей пространство/время. Если у человека мало времени, то он сосредотачивается на приоритетах и делает только самое важное. А если времени много (или кажется, что много), то делает много приятного, красивого, но малополезного, рационализируя это для себя такими понятиями как "качество кода", "расширяемость", "гибкость" и проч. И хотя в этих объяснениях есть рациональное зерно, полезность этих дополнительных качеств зачастую весьма малоощутима, и все было бы сделано значительно быстрее, и весьма незначительно хуже, если бы не было этого лишнего времени. Какое же пространство/время заполняет любая работа? Ответ - отведенное ей программистом. То есть если программист рассчитывает на то, что он сможет работать в выходные, то работа непременно займет эти самые выходные.

Теория № 2: большинство программистов регулярно недооценивает количество времени необходимое на выполнение задания. Можно обсудить отдельно почему так происходит, и у меня есть по крайней мере 3 теории на этот счет, но не будем отвлекаться на пустяки. Так вот, то, что программисты недооценивают сложность и время выполнения задания, бьет по ним дважды. Сначала тем, что они сообщают это заниженное время менеджеру, и он встраивает его в план, который потом не может или не хочет изменять. Но даже если менеджер уже собаку съел и не забыл умножить это время на три, то тут вступает в силу теория № 1, и программист, которому кажется, что времени у него дофига проводит первую половину проекта занимаясь всякими красивостями и финтифлюшками, и только к середине, после усердных пинков и требований показать что-нибудь работающее, осознает, что времени осталось мало, а работы как было так и есть непочатый край, и бросается на амбразуру.

Теория № 3: хорошие программисты всегда немножко художники, а артистический процесс часто происходит рывками и "запоями". Я в эту теорию сильно верила, пока сама была программистом-одиночкой, но предсказуемые коллективные "запои" в последнюю неделю перед сдачей как-то пошатнули мою веру. Если, конечно, программистская Муза не питается адреналином.

Главный вопрос, это как же нам так организовать программистский проект, чтобы люди работали с 9ти до 5ти (ну или с 11ти до 7ми, как приятнее) и заканчивали его легко и комфортно, как раз к дедлайну?

Comments

( 59 comments — Leave a comment )
starshoi
Sep. 3rd, 2008 02:34 am (UTC)
У тебя посылки неправильные. Отмени "мертвую линию" и все будут работать либо с 9 до 5 либо, если им интересно, столько, сколько захотят. Ты думаешь, что в банке люди работают до 5 потому что они по-другому устроены? Нет, у них нет дедлайна, они знают, что придут, а завтра будет опять такая же работа, зачем корячиться. А ты говоришь программисту, что завтра около полуночи упадет небо. Далее, в зависимости от организации дела и твоих теорий (в каждой из которых есть доля истины), они будут сидеть и как атланты, держать небо на каменных плечах. Подвиг потому что. Не говори ничего про подвиг, просто поймай нормальный темп работы, вычисли, когда в этом темпе что-то осязаемое появится и возьми его в этот момент.

:-)
_mak_
Sep. 3rd, 2008 02:48 am (UTC)
У меня по этому поводу один отмаз и два сомнения. :)))

Отмаз: как же я дедлайны отменю? Каждая группа программистов не работает в одиночку, и должна соотносить конечные и промежуточные результаты своей работы с другими группами программистов, юзеров, тренеров, писателей документации, тестеров и проч. Если мы не договоримся в какой день эта программа перейдет от программистов к тестерам, то либо я должна держать незанятых тестеров в ожидании когда же жареный петух клюнет, либо их там просто не будет в тот момент.

Сомнение № 1: допустим мы таки умудримся отменить дедлайн. А появится ли там вообще что-либо осязаемое? Программисты любят писать неосязаемое - кучки очень красивого кода, рассортированные по файликам. Только когда надвигается Небесное Падение они начинают собирать эти кучки в одну большую, и тут-то и выясняется, что чтобы реально заработало надо написать еще столько же, но совсем не красивого и жутко скушного кода, и их жутко ломает (и я их очень хорошо понимаю, но что же делать?) Вобщем я еще не видела программиста, который бы занялся таким малоприятным делом без дедлайна.

Сомнение № 2. Все-таки мерещится мне, что таки да, по другому устроены и завяли бы со скуки работать в банке. Тут у меня доказательств нет, просто такое кишечное, прости господи, чуйство... :)
(no subject) - starshoi - Sep. 3rd, 2008 02:59 am (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 03:14 am (UTC) - Expand
(no subject) - starshoi - Sep. 3rd, 2008 03:19 am (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 03:26 am (UTC) - Expand
(no subject) - starshoi - Sep. 3rd, 2008 03:31 am (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 03:34 am (UTC) - Expand
(no subject) - starshoi - Sep. 3rd, 2008 03:33 am (UTC) - Expand
raydac
Sep. 3rd, 2008 04:33 am (UTC)
думаю, что срабатывает эфект "студента", т.е. люди работают со всё увеличивающимся КПД чем ближе срок сдачи
_mak_
Sep. 3rd, 2008 12:51 pm (UTC)
Что же нам сделать, чтобы они сразу увеличили КПД?
(no subject) - raydac - Sep. 3rd, 2008 12:58 pm (UTC) - Expand
yakov_sirotkin
Sep. 3rd, 2008 04:35 am (UTC)
У меня другие экспериментальные данные - я сам программист и по выходным не работаю. Но при этом с 9 до 5 я никогда не работал в принципе: моя работа заключается в делании законченных кусков - иногда на это может уйти 4 часа в день, иногда 12.

Но я знаю практически гарантированный способ, чтобы программисты работали в выходные - надо им за это платить, желательно по повышенной ставке.
raydac
Sep. 3rd, 2008 05:00 am (UTC)
как я понял, Маша подразумевает процесс изготовления законченного продукта, а не частей к нему и не обслуюивание какой то сложной системы в рамках обслуживания
(no subject) - _mak_ - Sep. 3rd, 2008 12:54 pm (UTC) - Expand
(no subject) - raydac - Sep. 3rd, 2008 01:00 pm (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 01:22 pm (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 12:52 pm (UTC) - Expand
(no subject) - yakov_sirotkin - Sep. 3rd, 2008 01:15 pm (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 01:20 pm (UTC) - Expand
(no subject) - raydac - Sep. 3rd, 2008 01:34 pm (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 01:40 pm (UTC) - Expand
(no subject) - raydac - Sep. 3rd, 2008 01:50 pm (UTC) - Expand
vit_r
Sep. 3rd, 2008 04:45 am (UTC)
Когда авралы перманентны, это значит такая культура. Или за это платят.

Есть двухнедельные циклы продуктивности.

Ещё "в любые сроки можно вписаться, если не фиксировать качество". В "таком-же" проекте, выполненном за большее время, окажется больше документации, более разумная структура, может ещё люди чего нового подучат.

В принципе, проектов без авралов с выполнением работы больше намеченной, я тоже видел достаточно.
_mak_
Sep. 3rd, 2008 12:58 pm (UTC)
Более разумная структура, больше документации и прочие радости довольно быстро подчиняются закону diminishing returns. Иной раз такие навороты сооружают с присказкой "а вот может еще и это понадобиться". Ну да, может, с вероятностью 0.01%. Если понадобится, тогда и напишем.

Работу без авралов я видела только инкрементальную - починка багов по 5 в день, добавка маленьких фич. Задумать принципиально новый продукт и изготовить его без авралов - не видела.
(no subject) - vit_r - Sep. 3rd, 2008 09:22 pm (UTC) - Expand
_radiant_
Sep. 3rd, 2008 06:24 am (UTC)
А как насчёт вести двойную бухгалтерию? :)
"Черную" -- со сроками, которые указали сами программисты.
"Белую" -- ту самую, которая *3, для внешних (начальство, другие команды, etc.)

Как бы и воспитательная вещь: программисты начинают оценивать сроки правильно (теория 2).
Ну и как противодействие теории 1.

В нашей команде есть ещё теория 4 - команда занимается не только разработкой, но и поддержкой старых версий, и исправление ASAP багов сильно корежит придуманное расписание...
_mak_
Sep. 3rd, 2008 01:03 pm (UTC)
Двойная бухгалтерия - это тема богатая, но в большинстве случаев неосуществимая. Если тестеры знают дату, когда программа к ним придет, то и от программистов эту дату не скроешь. К тому же, по-моему, это должно быть унизительно программистам - они ж не в детском саду чтобы их так морочить. :)

Теория № 4 - точно, такое дело тоже есть. :)))
(no subject) - _radiant_ - Sep. 3rd, 2008 02:56 pm (UTC) - Expand
alll
Sep. 3rd, 2008 07:48 am (UTC)
Программистская Муза таки питается адреналином.
Кстати, замечательная формулировка.
_mak_
Sep. 3rd, 2008 01:04 pm (UTC)
ох уж мне эта Муза :)))
averros
Sep. 3rd, 2008 09:00 am (UTC)
Гы. Для того, чтобы программисты работали, им нужен начальник, которого они уважают и хотят показать себя перед ним с лучшей стороны. И которого слушают и с которым соглашаются (а не просто сдаются с присказкой про зулусов и бусы и про ну их нах).

Для этого начальник должен уметь делать их работу лучше, чем они сами. Опять же, они такому начальнику лапшу на уши по части сроков вешать не смогут - да и не захотят.

Главная же забота начальника - после подбора команды и организации работы над проектом - отгонять манагеров с их дедлайнами и прочим манагерским идиотизмом как можно дальше от программистов, чтобы не мешали работать. Потому что быстрее, чем оно делается, никакими манагерскими ужимками и прыжками проект делаться не заставишь. Можно только создать суету, результатом которой будет сделанное впопыхах говно - и бесконечные баги, исправление которых займёт куда больше времени, чем было "сэкономлено" спешкой.
just_developer
Sep. 3rd, 2008 09:39 am (UTC)
Кстати, по собственному опыту, - согласен
(no subject) - firstep - Sep. 4th, 2008 11:53 am (UTC) - Expand
(no subject) - averros - Sep. 4th, 2008 12:16 pm (UTC) - Expand
(no subject) - firstep - Sep. 4th, 2008 02:54 pm (UTC) - Expand
il_tat
Sep. 3rd, 2008 11:06 am (UTC)
Ну знаешь, здесь уже много советов было.
Но это действительно со студенческих времен начинается. Программисты это такой народ, долго раскачиваются и быстро едут.
Я все 5 лет курсовые также писал. На 5м надоело. Дипломный проект просто разбил на несколько этапов. На каждом этапе шел к руководителю отчитываться, принималась работа и приступал к следующему, последний этап отдельный был - это просто все скомпоновать в один проект. Без всяких бессонных ночей обошлось.

Работаю сейчас также. Сотрудникам также ставлю промежуточные этапы. И всегда вовремя все заканчиваем без "дедлайнов".

Есть еще один способ. Обсуждение проекта с программерами и так чтобы каждый алгоритм программ был более-менее обсужден и все это вбивается в бумагу, разбить работу по частям и дать программерам реализовать. Поверьте мне, реализация будет очень короткой. Во всех проектах очень много времени уходит на то чтобы донести до программера что от него хотят. Один проект, я так и сделал, кстати. Написал полную инструкцию, все условия, все пополочкам разложил и дал программеру. И он сделал именно то, что мне надо. И срок сдачи сократился в 3 раза. :)
alll
Sep. 3rd, 2008 11:19 am (UTC)
А если б инструкция была б написана прямо на языке программирования, то срок сдачи сократился б до нуля!
(no subject) - il_tat - Sep. 3rd, 2008 11:32 am (UTC) - Expand
(no subject) - alll - Sep. 3rd, 2008 04:02 pm (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 01:13 pm (UTC) - Expand
(no subject) - il_tat - Sep. 3rd, 2008 01:24 pm (UTC) - Expand
firstep
Sep. 3rd, 2008 03:16 pm (UTC)
Вот ведь странно. А мы уже давно у себя таких дедлайнов с ночным овертаймом не припомним. Все стабильно, в рабочем порядке.

Вот, буквально последний проект, релиз которого я, как CQE, задержал, так как посчитал его недостаточно готовым для выхода. И что, кто-нибудь стоял на ушах или выходил на работу на выходные, чтобы успеть к назначенному планом сроку? -- Ничуть! Часть команды, недоделавшая локализацию, вообще ушла на national holidays, а меня за неделю до окончания проекта проджект-менелжер отправил на тренинг, уверяя, что это важнее. Ну да, вышли из графика на 2 недели, но именно такая дельта и предполагалась в изначальных прогнозах, так что оценку проект получил адекватную и окончательному выходу продукта в продажу это не помешало.

Почему -- спросите -- у нас почти нет авралов? -- Трудно сказать. Но жесткого с 9 до 5 у нас нет как класс. Может, дело в привычке -- изжили мы их у себя. Может, заслуга менеджера -- он у нас вполне себе адекватный. Может, всему причиной процесс: работаем по Agile, Scrum и все такое, к вопросам планирования подходим аккуратно, в расчет capacity людсикх ресурсов берем только 80% реального времени сотрудника, оставляя 10% на maintanence предыдущих проектов и 10% на самообучение и профессиональное развитие, а сам человеко-день принимаем равным 4.5 часам.
_mak_
Sep. 3rd, 2008 05:46 pm (UTC)
А какого типа продукт вы пишете?
(no subject) - firstep - Sep. 4th, 2008 11:05 am (UTC) - Expand
(no subject) - firstep - Sep. 4th, 2008 11:34 am (UTC) - Expand
girit
Sep. 3rd, 2008 04:03 pm (UTC)
It is not just about programmers. I have experienced identical issues as individual analytical contributor as well as project manager, and sometimes as project manager responsible for the project performed by one contributor (myself), which is the worst. I am not sure, though, that the reasons are same - but in my world it is mostly explained by an 80% - 20% rule - a dichotomus illustration of the diminishing return curve - means that 80% of result can be achieved with 20% of effort. The rest - whole lot of effort - goes for achieving the remaining 20%, or fine tuning.

According to that rule, one needs to spend an effort on completing the main part of work (the 80%) and than, if there is time - 20%. But in reality the work is happenning consequitively and it is not possible to go back. When we schedule our effort, we schedule as if we are shooting for 100% of work, and we work in that mode untill we run out of time (because we spend majority of effort on the flattening areas of the curve). We than quickly complete the remainder, now shooting for only 80% of work / qility and using 20% of effort. But this 20% is usually overtime, because we would work as long as possible on the 100% - 100% schedule (because it is comforting to do high quality work at easy pace).

Not sure how clear I am explaining myself but gota run, cause I am having exactly that type of issue right now. :)

_mak_
Sep. 3rd, 2008 05:51 pm (UTC)
Then the answer is to make project plan that forces doing the 80% first (and in 20% of the time). The interesting aspect of it is that this kind of schedule seems the most "idiotic" (read counterintuitive) to the programmers and takes a lot of trust and other influence to convince them to go along.
(no subject) - girit - Sep. 3rd, 2008 06:54 pm (UTC) - Expand
(no subject) - _mak_ - Sep. 3rd, 2008 07:10 pm (UTC) - Expand
jdevelop
Sep. 3rd, 2008 07:18 pm (UTC)
Я голосую за теорию под номером два, потому что и из собственного опыта, и по каждому из команды могу с уверенностью сказать - при оценке своего времени программист как правило не учитывает того факта, что на написание кода уходит время, на отладку любой мелкой ошибки тоже уходит время, в конце концов на написание юнит теста может уйти даже больше времени, чем на собственно функциональный код.

С другой стороны, коэффициент X берется для каждого человека отдельно, а как сумму этого коэффициента считать для команды (параллельно или последовательно) - никто еще не придумал.

Можно делать RUP, можно делать XP, но как уже сказали выше - все зависит от задачи, на исправление багов и поддержку время можно прогнозировать с точностью до дня, на странные проекты с новыми технологиями - минимум три разных срока (оптимистический, реалистический и пессимистический), причем оптимистический проставить дедлайном программистам, реалистический отдать менеджерам, а пессимистический - заказчикам, тогда есть практически 99.9% вероятность, что в пессимистический прогноз (а чаще всего в реалистический) удастся уложиться и без овертаймов.

Оптимистический срок берется на основании мыслей самого опытного члена команды в разработке подобных проектов, реалистический умножается на X, и пессимистический получается умножением реалистического срока на Y, где X и Y определяются эмпирическим путем.

Как-то так.
_mak_
Sep. 4th, 2008 12:23 am (UTC)
Ага, насчет персональных коэффициентов это точно.

- Тютькину на это понадобится неделя.
- Это Тютькин тебе сказал неделя или ты мне говоришь, что неделя?
- Какая разница?
- Буду знать на сколько умножать. :)))
(no subject) - jdevelop - Sep. 4th, 2008 06:59 am (UTC) - Expand
kruzo007
Sep. 3rd, 2008 10:07 pm (UTC)
_mak_
Sep. 4th, 2008 12:20 am (UTC)
Я всего этого Голдратта читала. Тут проблема другая по моему. Как планировать время необходимое на работу если скорость работы переменная и зависит от восприятия этого самого времени.
(no subject) - kruzo007 - Sep. 4th, 2008 01:50 am (UTC) - Expand
(no subject) - _mak_ - Sep. 4th, 2008 01:54 am (UTC) - Expand
netklon
Mar. 9th, 2010 07:24 am (UTC)
Вы написали этот пост полтора года назад. Какая из озвученных теорий подтвердилась? Как проблема авралов перед дедлайнами видится вам сегодня?
_mak_
Mar. 10th, 2010 03:28 am (UTC)
Боюсь, что теориям такого рода не суждено "подтвердиться" - статистического исследования с контрольными группами мне не организовать. :-)

Но я лично все более уверяюсь в практически универсальной справедливости теории № 1 (перфекционизм). Теории №2 (наивный оптимизм) и №3 (неконтролируемый артистизм) тоже иногда имеют место быть, но не всегда, и, даже когда существуют, создают меньшие искажения в проектном плане.
( 59 comments — Leave a comment )