Михаил затронул интересную тему в комментах к предыдущему постингу: задачи и ответственность некого “руководитела команды”.
В частности он говорил о том, что все наши “неудачи” в начале процесса связаны с плохим “руководителем команды”, а если этого руководителя нет, то “и не удивительно” :)
Тема мне показалась интересной, а утверждение – спорным. В частности и потому, что “неудачи” были успешно пофиксены, а “руководитель команды” так и не появился. Просто мы стали командой. И всё.
Поэтому давайте рассмотрим, что же это за позиция такая: “руководитель команды”? Позиция, кстати сказать, весьма распространённая.
Итак, в чём заключается роль “руководителя команды” (они любят называть себя ПиЭм, поэтому я тоже буду использовать эту аббревиатуру, хотя это неверно).
- Управление требованиями, приоритетами задач, функциональностью релизов.
- Прямое руководство командой программистов.
Программисты находятся в прямом официальном подчинении у ПиЭм’а. - Распределение задач между программистами, сроков выполнения этих задач, а так же отслеживание результатов.
- Поддержка формальной методологии разработки ПО.
Вроде на этом всё. Рассмотрим по пунктам.
Начать хочется с пункта 4, как самого интересного :)
Интересного в этом пункте то, что формальные методологии процесса разработки практически умерли, доказав свою неэффективность.
Перефразируя Ладыженского:
”Умер RUP.
Это много страшнее других смертей.
Обалденно стою
Над потерей потерь.”
То есть, найти в применении что-то, что не-agile сейчас действительно проблематично. А Agile – это уже даже не методология, а процесс… Тот же SCRUM, пожалуй один из самых распространённых в мире процессов. Тот же канбан, который, видимо, набирает силу (но к которому я отношусь с подозрением). Всё это происходит от того, что издержки от “тяжёлых” методологий велики.
“Тяжёлые” методологии умирают. Об этом же пишет Том ДеМарко, один из основоположников всего этого дела и автор книги “Controlling Software Projects: Management, Measurement, and Estimation”. Он в своей статье прямо пишет:
“In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.”
В статье он называет самого себя “юным автором, которому нравились метрики” и заявляет о том, что всё это оказалось неверным.
Оригинал можно почитать тут: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
Перевод – здесь: http://bishop-it.ru/2009/07/softwareengineeringisdead/
В действительности, поддержка “тяжёлых” методологий – это достаточно большой и не нужный кусок работы.
Перейдём к пункту 3.
Имея на руках задачи (об этом позже), кто может сделать разбивку задач на технические “таски”, сделать оценку сложности работ, оценку приблизительного времени исполнения лучше, чем сама команда разработчиков? Некий “руководитель”, который придёт и скажет потом “Вася с Петей делают то-то, у вас неделя, Миша, Маша и Маня – вот это, у вас 8 дней”? Да не смешите, это не работает :) Но даже если это сработает с определенной поправкой (допустим, “руководитель” хорошо знает способности всех пятерых), то это всё равно не будет лучше, чем если бы это сделали сами исполнители.
К тому же, в подавляющем большинстве случаев, программисты знают код и архитектуру лучше, чем любой волшебный ПиЭм :) Поэтому оценки будут вернее.
Есть ещё один аспект: команда может перераспределять подзадачи внутри себя. Никакой “ПиЭм” ей для этого не нужен. А эффективность возрастает существенно по сравнению с тем, что Вася сидит и делает данный ему “свыше” таск – практика.
Кстати, о том, что “нет руководителя – неудивительно”. Когда команда принимает решение – это делает именно команда. То есть, несколько человек. В процессе обсуждения.
Если мы “выцепим” одного из процесса, фактически из той же команды, и заставим его одного принимать решения – риск ошибки и негативных последствий только возрастёт.
О контроле за процессом разработки. Тут даже говорить-то не о чем – весь контроль – это фикция, сводящаяся к назойливому ежедневному (хорошо если не ежечасному) “ну, как продвигается?”. Да невозможно узнать “как продвигается” лучше, чем знают это конкретные исполнители. И если дать возможность команде самоорганизовываться – она станет способна решать эти проблемы. Сама.
О пункте 2. Простой вопрос: зачем?
При отсутствии фигни из пункта 3 отпадает всякая необходимость и в этом.
Наконец, пункт 1.
Это очень важный и нужный кусок работы. Серьёзно. Но фишка в том, что он никак не связан с “руководством команды”. Это просто кусок работы, который должен кто-то делать. Этот “кто-то” не является руководителем, не находится ни выше, ни ниже тех же программистов и тестеров. Так же, как и последние две (программисты и тестеры), эти специалисты представляют собой независимую ветвь.
Важно: они ничего никому не приказывают, никакими программистами не руководят. Они организовывают требования, описывают их с точки зрения будущего продукта, определяют, в какой момент жизни продукта в нём должна появиться какая функциональность и т.д.
Поэтому этот пункт мы отбрасывать не будем.
Итак, у нас осталась разработка требований, которая с руководством не связана.
Теперь давайте посмотрим на типичную команду, имеющую “руководителя-ПиЭма”. Кто он?
В 90% случаев (я видел только таких, но пишу 90%, мало ли :)) это люди, которые работали сначала разработчиками, потом.. как это по-русски.. senior software developer, а потом типа “выросли” до ПиЭма. То есть – программеры-переростки :)
Что такие люди знают об управлении требованиями? Об управлении людьми (буде они таки собрались ими управлять)? Об управлении чем-либо вообще? Ни-че-го. Хорошо, если книжек про это почитают.
И это хорошо ещё, если этот человек таки действительно занимается требованиями. Ибо часто бывает, что требованиями занимаются другие, например, непосредственно менеджмент, или представитель заказчика, а такой вот ПиЭм является просто переносчиком информации (вопрос “как продвигается” остаётся в силе).
Теперь задумайтесь: “повышая” (а посути понижая) хорошего разработчика до такого вот “руководителя команды” мы:
- Теряем высококвалифицированного специалиста.
- Получаем неквалифицированного (низко квалифицированного) человека, занимающегося требованиями.
- Вынуждены платить большие деньги этому человеку на новой позиции.
- Теряем гибкость и чёткость работы команды именно как команды, а не как Васи, Пети, Маши, Миши и Мани, делающих то, что в данный момент велел “руководитель”. Поверьте, именно командная работа существенно улучшает конечный результат.
- Увеличиваем риск ошибки (одна голова хорошо, но две – лучше). К тому же, та же самая голова никуда и не девается.
Скрипач не нужен…
Получается, что гораздо выгоднее перейти на рельсы самоорганизации команды, сделать её именно командой, вернуть такого программера-переростка на место, получив обратно +1.5 к programming skills в комманде.
А для работы с требованиями программист не нужен. Достаточно усердного человека, хорошо разбирающегося в офисе с минимальными навыками в программировании на уровне сделать запрос в ACCESS или простейший макрос на Office VB, чтобы просто понимал, что за магию творят другие :)
И станет он разбираться в продукте с “внешней” его стороны, и станет он распределять приоритеты необходимой для релиза функциональности, и станет он описывать требования ну никак не хуже вышеописанного ПиЭма. :)
Subscribe
Windows Live Alerts