7 способов вызвать ненависть разработчика (краткое руководство для заказчиков)

(UPD. Перенесла в ХабраЮмор. Господа, не воспринимайте все так серьезно :-) )

Что делать заказчику, который начинает новый проект с командой разработчиков и хочет оставить по себе долгую и яркую память? Следуя несложным советам этой статьи, вы сможете вызвать самые бурные эмоции за считанные недели даже у совершенно незнакомых людей.

Присылайте требования в файле Excel, а скриншоты ошибок — в Word

Разработчик — счастливый владелец рабочего компьютера образца 2005 года — получит массу удовольствия, пытаясь открыть мегабайтный файл, перекапывая все сто листов требований в поисках двух строк изменений и увеличивая масштаб просматриваемого файла, чтобы рассмотреть скриншот. Желательно также делать скриншоты максимально неинформативными, чтобы ваша приятная переписка подольше не заканчивалась. Еще можно творчески подойти к описанию проблемы, отображенной на скриншоте: лучше всего работает фраза «Посмотрите, пожалуйста!» (не забывайте смертельно обидеться на ответ «Посмотрели!»).

При оформлении таблиц проявляйте креативность

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

Меняйте требования не меньше двух раз в неделю

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

Назначайте тестирование и внедрение продукта на летнее время

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

Требуйте присутствия разработчиков в вашем офисе

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

Никогда не заказывайте для разработчика пропуск

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

Никогда не кормите разработчика

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

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