Сайт как бизнес

Поисковое продвижение сайтов (SEO), создание сайтов в Минске (Беларусь).

Подпишись на рассылку блога об интернет-бизнесе:

Архивы за февраля, 2013

Как заказчику демотивировать разработчика?

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

Интересную заметку нашел. Взгляд со стороны программиста на хитросплетения процесса удовлетворения заказчика разработки ПО. Приведу ее целиком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Александр Томов

Написал admin

24 февраля, 2013 в 10:27 дп

Подпишись на обновления блога по e-mail или RSS!