Управление проектами

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

1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?

Как правило, отвлекают от работы вопросом, сбивают с потока. Просят назвать срок, когда неизвестна ни задача, ни требования, только одно предложение. И так настойчиво, что, чтобы отвалили, называешь прикидочный срок.

Менеджеру: поймите, что программист строит в голове модель будущей системы. По одному предложению нельзя смоделировать приложение. И только ваша вина, если вы не потрудились уточнить ТЗ (это ваша работа, кстати) у заказчика, а хотите сразу назвать ему срок (и цену). Потому что оценка с потолка невозможна — вроде как ответить на вопрос «сколько времени займет покрасить комнату неизвестной площади?».

2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)

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

Менеджеру: ничто так не демотивирует, как обвинение в некомпетентности и лжи. Постарайтесь давать точное ТЗ и бить задачу на простые кусочки, в чем программист с удовольствием поможет (если хорошо попросить). Тогда можно будет более точно управлять сроками.


3. Глянь срочно, тут надо за час сделать табличку! (кидается ссылка на чужой код)

Работу программиста можно сравнить с работой художника. Программист максимально фокусируется на задаче, как художник — на всех деталях объекта, и держит в голове очень сложную картину. По исследованиям, не менее 15 минут требуется, чтобы вернуться в состояние «потока», когда отвлекли. Поэтому отвлечение очень раздражает — есть отличная статья «Не будите программиста» (полезная статья для программиста в тему — как работать в потоке). А особенно — отвлечение на чужой код, который никто не любит.

Менеджеру: постарайтесь построить работу так, чтобы утром давать задачи, а вечером принимать готовый результат. Днем обеспечить максимальную тишину программисту, чтобы его не отвлекать. Это будет работать на вас — так как эффективность работы будет гораздо выше, чем если постоянно дергать. Кстати, свободный график также мотивирует людей — доверяя им, вы показываете уважение, а люди это ценят.



4. Никакого рефакторинга, мне это нужно сегодня!

Стройный ациклический идеальный граф зависимостей всегда ломается с новым «бизнес-требованиями». И чем больше грязного и некрасивого кода, тем меньше он мне нравится, как программисту. И тем меньше с ним хочется работать, особенно когда не дают переписать нормально. А со временем говнокода становится так много, что любые изменения вносятся хардкодом и хаками. И однажды проект просто загнивает, и становится проще переписать с нуля, что вызывает ужас и бешенство менеджеров.

Менеджеру: работа над кодом во время постоянных изменений и доработок проекта чем-то похожа на игру «опрокинь». Строится башня из деревянных палочек, и палочки в основании вынимают одну за одной. Основная задача — не опрокинуть башню. Так вот, при внесении изменений требуется время, чтобы проект не рушился, как башня, чтобы его структура была устойчивой к новым изменениями. Давайте день в неделю на рефакторинг, не меньше, иначе однажды проект придется переписать с нуля, что обычно дорого, невозможно и есть следствие вашей вины.

5. Сверстай по-быстрому это, пожалуйста, и лучше на extJS.

Во-первых, я не люблю верстку. Это особая работа, и ее должны делать профессионалы, которые обладают усидчивостью. Вообще, я уважаю верстальщиков — уметь сверстать так, чтобы везде было одинаково, это мастерство и очень круто. Просто руки к этому не лежат. Но во-вторых, как программиста, меня всегда бесит, когда менеджер лезет в мою среду и пытается мне доказать, что я не прав, что верстать надо не на дивах и не верстальщику, а мне и на extJS, потому что вчера он прочитал об этом на Хабре, поняв только 10% слов и запомнив название JS библиотеки.

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

Напоследок

Добавьте в комментариях, что вас бесит в работе ваших менеджеров, и попробуем сделать мануал, чтобы было куда дать линк RTFM.

Менеджеру: уважайте труд своих программистов. Помни, программист — тоже человек, %username%.

Upd.: в статье описаны, по сути, антипаттерны взаимодействия менеджера и программиста. Конечно, адекватный менеджер так себя не ведет, а адекватный программист рано или поздно встретит хорошего менеджера. Я в это верю. :)

http://habrahabr.ru/post/167451/