[work] Вообще-то я вовсе не против менеджеров, но вот планы…

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

Начну издалека, из детства :) В детстве, а затем и в юности, меня донимал вопрос: “Зачем оркестру дирижер?”

Ну действительно, зачем? Ведь у каждого музыканта есть ноты, каждый должен просто играть свою партию и всех делов. Вот в рок-группах, например, дирижеров нет, а как играют! Так зачем же дирижер оркестру?

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

Затем мне пришлось столкнуться с организацией командной работы над общим программным проектом во время учебы в университете. Вот тут-то и наступило прозрение :) Привести к общему знаменателю даже двух творческих индивидов крайне не просто, а уж если их не двое, а трое, четверо, пятеро… И у каждого свои тараканы в голове взгляды на то, как делать правильно, то задача становиться совсем безнадежной. Обязательно должно быть единоначалие. Обязательно должна быть одна голова, которая служит мерилом и арбитром. Причем не обязательно эта голова должна все придумывать или принимать абсолютно все решения, включая самые мелкие. Но общее направление движение должно определяться одним человеком – менеджером проекта.

Поэтому менеджмент – это обязательное условие успешности любого проекта, в котором занято более одного человека. Да и в случае одного разработчика наличие менеджера так же не помешает, т.к. хороший разработчик есть человек творческий, а у творческого человека в проекте могут быть несколько иные цели и приоритеты, чем у заказчика проекта. Как раз менеджер будет обеспечивать более-менее точное совпадение целей/приоритетов у заказчика и исполнителя.

Так что я вовсе не против менеджмента :)

Только вот какая штука. Почему-то (и не так уж редко, к сожалению) между ПМами и разработчиками возникает состояние холодной войны. Уж не знаю, что думают ПМы о разработчиках, но бывает, что программисты поминают ПМов исключительно незлым тихим словом, встречая каждое новое указание от менеджмента риторическим вопросом “Да вы что там, *банулись все, что ли?” :(

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

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

Для демонстрации своей мысли ударюсь в демагогию и приведу аналогию. Допустим, вы планируете работы по капитальному ремонту ванной комнаты в своей квартире. При наличии опыта в этой сфере список предстоящих работ можно выстроить весьма полный и довольно точный:

• демонтаж двери и дверной коробки;
• демонтаж сантехнического и другого оборудования;
• удаление старой плитки (стены, пол) и других элементов декора;
• демонтаж старых труб (вода, канализация);
• демонтаж старой электропроводки;
• штробление стен/пола для укладки новых труб;
• новая стяжка на пол + гидроизоляция;
• установка новых труб (вода, канализация);
• штробление стен/потолка для новой электропроводки;
• укладка новой электропроводки;
• выравнивание стен;
• укладка плитки (стены, пол);
• конструкция потолка и других элементов декора;
• монтаж нового электрооборудования (розетки, осветительные приборы);
• монтаж нового сантехнического и другого оборудования;
• установка новой дверной коробки и двери.

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

Однако, план этот совершенно бесполезен без самой важной штуки – дизайна будущей ванной комнаты. Поскольку не имея дизайна, вы не сможете сказать сантехнику где должен располагаться смеситель и он не сможет провести туда трубы. А электрик не сможет провести проводку, если вы не знаете, нужны ли вам точечные светильники на потолке (на 220 вольт или 20 вольт, врезанные в подвесной потолок или скрытые под натяжным потолком) или же это будут размещенные на стенах лампы.

А теперь попробуйте составить план-график разработки дизайна ванной комнаты!

Сколько вам нужно времени, чтобы определиться с видом потолка – простой крашенный, подвесной из ПВХ-панелей, натяжной? День, два, три? Сколько раз вы передумаете и измените свое мнение после посиделок у Ивановых или после рассказов о недостатков похожей конструкции у Сидоровых? Какой процент прогресса в этом занятии вы выставите через день? Или через неделю?

Сколько вам нужно времени, чтобы выбрать плитку? На пол. На стены. Будет ли вообще плитка и там и там, или же нужно что-то другое? Если будет плитка, то какая: мелкая, обычная, крупная? Или их сочетание? Если сочетание, то какое? Плитка чьего производства, по какой цене, какого цвета и рисунка, в каком магазине, когда будет в наличии? А теперь укажите прогресс в данном вопросе в процентах!

Какая вам нужна ванна? И нужна ли вообще? Может лучше душевую кабину – с мелким поддоном? Или с глубоким? А какая должна быть раковина? И где она должна стоять? А будет ли она мешать стиральной машине? А если стиральная машина со временем поменяется? Насколько процентов вы реализовали данную задачу за прошедшую неделю?

Так что все-таки на счет план-графика создания дизайн-проекта? В каком порядке должны выстраиваться конкретные работы? Какие между ними зависимости? Какова их длительность? Насколько актуально будет вести отчетность об этом процессе в Project-е? И опять же, почему не проставлены проценты в текущих тасках?!!! ;)

Теперь к сухому остатку. Надеюсь, что приведенный мной пример показывает, что как только возникают творческие вопросы, так сразу планирование становится не ремеслом, а искусством. А программирование занятие особое – оно сочетает в себе как дизайн, так и конкретные технические работы. Но дизайна все-таки побольше, поскольку характер разработки ПО таков, что чаще приходится писать новые программы (т.е. заниматься дизайном), а не переписывать старые (т.е. повторять одни и те же действия снова и снова). Посему и способы планирования и контроля за ходом работ, которые хорошо работают, скажем, в строительстве, не очень гладко и безболезненно ложатся на разработку ПО. И я, как программист, это хорошо чувствую. О том и пою :) Но я вовсе не против менеджмента ;)