Sat 10 Feb 2007
Прогулки по граблям, часть 1
Posted by Alex Lebedev under менеджмент, процесс разработки
Прочел вот здесь:
Недавно обсуждал со своем начальником следующий вопрос: Как лучше разделять задания для выполнения по проекту. Есть два мнения: необходимо делить проект на мелкие части и выдавать части любому свободному программисту, размер части не более 8 часов - одного рабочего дня - так думаю я и программисты в моей команде. Мнение начальника - выделять в проекте большие блоки и назначать ответственных за каждый блок, что бы он постоянно отвечал за него и в случае наличия проблемы решал ее.
Не могу спокойно смотреть, как люди ходят по граблям… Попробую высказать свои мысли по поднятой теме.
Затронуто, по сути, два вопроса - о единице планирования и о ротации разработчиков. Сегодня я расскажу про планирование.
О единице планирования
Много написано о том, что работы в плане должны быть максимально подробными. Джоэль Спольски, насколько я помню, пишет о 8-16 часах как о максимальной длительности, после которой задачу надо дробить на несколько более мелких. Техника действительно полезная, но там акцент делался на персональном планировании или, на худой конец, о группе из 2-3 человек.
Ну а если пытаться делать то же самое в относительно крупном проекте?
Представим себе первый вариант в действии. План дробится на мелкие задачи, которые раздаются разработчикам по мере завершения ими предыдущих задач. Не забудем о том, что автор пишет о том, что задачи выдаются любому программисту, по мере освобождения оных.
Итак, Константин Теркин, архитектор БД и программист серверной части, приходит в понедельник утром на работу. На выездном семинаре руководителей, проводившимся в предшествующие выходные, была принята уже известная нам стратегия планирования и даже создан общий пул задач на ближайшую неделю. В результате деления задач Константин должен за понедельник перевести на работу через Ajax форму редактирования данных о пользователях. С помощью документации, найденной в интернете, коллеги, разбирающегося в Ajax и такой-то матери работа была сделана, пусть и заняла не планируемые 6 часов, а все 11. Усталый, но немного довольный, наш герой отправляется домой.
Во вторник Константину достается задача по реализации возможности комментировать основные объекты системы. Сцена с погружением в документацию и призывами к такой-то матери повторяется. На этот раз успеть все за день не получилось, и работа переносится на среду. Усталый и невыспавшийся, Константин доделывает функцию комментирования только в среду после обеда. Следующей доставшейся ему задачей оказалась модификация схемы БД и хранимых процедур, нужная для какой-то новой функции. Наконец-то что-то знакомое! И Константин без проблем справляется с новой задачей.
В следущее утро ему досталась задача по модификации билд-файлов и перенастройке билд-сервера. Что ж, надо опять лезть в документацию… Через пару часов прибегает взмыленный тестер – выясняется, что написанный в понедельник Ajax-код, некорректно работает в седьмой версии Internet Explorer, а в 6-й версии и Опере не работает совсем. Документация по билдам заброшена и вдвоем с хорошо разбирающимся в Ajax коллегой Константин к концу дня таки исправляет этот чертов глюк.
В пятницу утром прибегает тестер, проверявший функцию комментирования…
Ну как вам такой распорядок?
“Да вообще отвратительно, убила бы такого руководителя” - одна моя хорошая знакомая.
В чем ошибка?
Не все задачи одинаковы. Не все программисты одинаковы. Я уже писал раньше о том, насколько чревато думать, что можно безнаказанно тасовать задачи, не учитывая особенности каждого конкретного исполнителя.
Планы должны быть предсказуемы. Когда человек не знает, что он будет делать завтра – это нонсенс. Не меньше половины ключевых идей для решения какой-то проблемы возникает у людей в «фоновом режиме», пока они работают над предыдущими задачами. Если человек не знает что через неделю он будет решать задачу X, то он легко может думать «в фоне» о решении для задачи Y. А решать придется задачу Z, про которую он не думал вообще. В итоге качество решений, требующих тщательного обдумывания снизится в проекте где-то в два раза. Оно вам надо?
Планы должны быть предсказуемы, часть 2. Люди чисто психологически не любят неожиданностей. Делая каждую следующую работу неожиданной вы сильно напрягаете всех участников проекта. Не буду говорить здесь о важности здоровой психологической обстановки в проекте – думаю что это очевидно для любого хорошего менеджера.
На сегодня все. В воскресенье читайте продолжение, про ротацию программистов.
11 Responses to “ Прогулки по граблям, часть 1 ”
Comments:
Leave a Reply
Trackbacks & Pingbacks:
-
Pingback from Прогулки по граблям, часть 2 » Outsourcing stories
February 11th, 2007 at 09:55[…] Продолжение предыдущей части, где речь шла о печальных последствиях планирования только на уровне деталей, без видения целого. […]
February 10th, 2007 at 10:22
Интересно. Раньше я тоже думал, что надо выделять большие блоки и назначать ответственность. Сейчас я думаю, что компромисс где то посередение - есть специализация программиста - база, дизайн, серверная часть и т.д., и имеет смысл задачу дробить на небольшие куски, но раздавать их не случайным людям, а людям, специализирующимся в данной области.
P.S.
Такое чувство, что что то сбойнуло где то, поэтому попробую выложить комментарий ещё раз.
February 10th, 2007 at 11:49
Единицы планирования могут быть хоть до 1 часа, есть уровни детализации. Если манагер хочет видеть проблему глобально
- пусть смотрит не на самом низком уровне детализации. В чем проблема?
February 10th, 2007 at 12:22
Это не сбой, это премодерация. Следующие комменты от того же человека (имя + email) должны появляться сразу.
February 10th, 2007 at 12:40
Проблема в том, что человек фактически предлагает планировать на самом нижнем уровне, без верхних. Есть задачи по 8 часов, которые раздаются по одной первому же освободившемуся программисту. Это как на машине ехать, глядя на свой капот и не метром дальше… Ну а получающийся в результате хаос я попытался описать в этом посте.
Кроме того, единицы планирования в 1 час при управлении командой - это миф. Часовое планирование возможно только на индивидуальном уровне и только если эти планы строго приватны. Почему?
Детализация до часа даст 8 * 5 = 40 задач в неделю с одного программиста. Теперь представьте что у вас их 10 человек - ни один менеджер не сможет разобраться в сотнях новых задач каждую неделю, даже если это его единственная работа (а это далеко не так).
В рабочем дне отнюдь не 8 рабочих часов. Люди, особенно в офисе, эффективно работают, дай бог, треть от этого времени, а остальное уходит на всякую, иногда необходимую, фигню. Как система планирования будет учитывать что у Кости в понедельник было 1,5 рабочих часа, а во вторник 9, а у Андрея - ровно наоборот? Я уверен, что если это и возможно, то явно неоправданно.
February 10th, 2007 at 01:20
К сожалению вы не совсем поняли назначение деления задачи на 8 часовые отметки и не совсем внимательно прочитали того же Спольски ) Основные принципы, которые он затрагивал:
1. Время работы назначают сами разработчики
2. Задачу длиннее 8 - 12 часов работы (именно работы) нужно разделить на несколько
3. Работники выставляют время, реально затраченное на решение задачи.
Из этого можно вывести следующее: большой блок задач разбивается на мелкие части, после этого раздается разработчикам по тем областям, где они специализируются. Разработчики сами выставляют (исправляют) время разработки фичи, менеджер поправляет данные/делит задачи мельче. Все пошла работа. Основной задаче этого является точное определение места команды в пути разработки (коряво получлось, ну да ладно)
February 10th, 2007 at 01:25
Прочитал предыдущую статью про Проджект ))) Спольски вами понят хорошо, беру свои слова обратно ) но, к сожалению, мой вопрос не понят почти совсем )
February 10th, 2007 at 10:45
Да, поставленный вами вопрос, я очевидно, интерпретировал совсем не так. Я так понимаю, уточненная формулировка звучит следующим образом:
Планирование без вникания в детали действительно возможно только если проработку этих деталей можно полностью делегировать проектной команде и получить на выходе приемлемый результат. Такая ситуация - редкое исключение, потому что даже у самой хорошей команды, как правило, куча других задач, а детализация общего плана и мониторинг его выполнения - одна из основных задач менеджера проекта.
Соответственно, иметь детализованный план гораздо лучше чем не иметь оного. Только вот предсказать общую длительность часто бывает невозможно, потому что план обычно ломают не плохо оцененные работы, а работы необходимость которых не удалось предвидеть. Тот же Джоэль пишет о том, что отладка и непредвиденные работы занимают от половины до двух третей всего времени проекта.
February 11th, 2007 at 04:45
Как это происходит у нас:
Реально пулом задач по проекту заведует project manager.
По мере освобождения программиста от предыдущей задачи (или по мере поднятия приоритета новой) менеждер выбирает наиболее подходящего программиста для новой задачи (опыт программиста, его желание заниматься новой задачей, текущая загруженность - всё имеет значение и должны быть учтены менеджером).
Задача почти равна “направлению”. Т е если речь идёт допустим об статистике по приёму почты, статистика по отсылке файлов тоже скорее всего должна быть выдана тому же программисту.
Человек сам представляет план выполнения работы (кстати близко к Spoelsky). Потом он сам же контроллирует его выполнение и если что не так - сообщает менеджеру чтобы он согласовал сроки/деньги и/или скоординировал усилия с другими программерами (если задачка оказалась “не по зубам”).
Понятное дело что все баги, все дополнения и близкие по сути проекты отдаються тому же человеку. Если он допустит ошибку в дизайне или реализации - исправлять будет он её сам. Пожизненный саппорт этой задачи (да и всего направоления) висит на этом программере. При желании направление и/или задачу можно передать кому то ещё (типа надоело или стало тривиальным).
Вот так.
March 1st, 2007 at 01:45
Еще вроде Брукс писал, что программистов считать по головам - занятие интересное, но безперспективное
Только не совсем понимаю, почему программисты сами роют себе могилу:
вероятно, им глубоко наплевать на судьбу проекта, а больше интересует возможность поколупать новые технологии, хотя думаю такого режима не выдержал бы даже я, при всей моей любви к ковырянию в чем-нибудь новеньком… хотя, возможно это имееет смысл если все задачи примерно одинаковой сложности и базированы примерно на одинаковом наборе технологий, а все программисты примерно одинаковой квалификации
Например: один гуру бьет все на мелкие-мелкие задачки, и куча негров их решает
Ага, маразм… Но у меня сложилось впечатление, что менеджер как раз хочет определять только верхний уровень, а все остальное отдать на откуп разработчиков… а те просто хотят все проектирование переложить на менеджера, а самим - просто кодить в рамках задачи…
March 2nd, 2007 at 04:09
По здравому размышлению пришло в голову вот что: ситуация выглядит как конфликт между начальником и программистами… причины могут быть любыми, начиная от “эти манагеры много о себе думают”, “за такие деньги и работать?” и заканчивая “все равно ничего работать не будет” или “весь проект - полный бред”… в любом случае, программисты хотят по максимуму избавиться от какой-либо ответсвенности, как минимум, а как максимум - подставить своего начальника