Moron-driven development
Каждый раз читаю в сети (как здесь, так и на других IT-ресурсах) про негодование разработчиков от менеджеров — чего стоят все эти истории про создание бритвы! — и каждый раз задумываюсь: уж не в параллельной вселенной ли я живу? Или, может, всё куда проще, и людям, как обычно, свойственно валить свои косяки и проблемы на кого-то другого, а также делиться по принципу «мы vs они» и «свой vs чужой»?
По моему личному опыту разработки, в котором были самые разные проекты как по тематикам, так и по размерам, менеджеры — это как раз тот элемент работы, благодаря которому проекты в итоге успешно сдаются и получаются нормальными. А вот проблемы начинаются как раз тогда, когда за руководство проектом садятся разработчики, любящие гнуть пальцы на тему того, какие они крутые специалисты по всему, или, что ещё хуже, когда проектом руководит сам заказчик (или его представитель), в большинстве которых сразу просыпается «творческая личность», начинающая выдумывать такой бред, который многим даже и не снился.
О проектах, ведомых разработчиками, можно долго рассказывать, но чаще всего там всё довольно-таки прозаично и упирается в неадекватные шапкозакидательские оценки сроков исполнения, абсолютно ублюдочную проработку интерфейсов, логики работы и юзабилити (ведь это всё «не нужно», «тут всё ясно и дебилу»и т. д. ), посредственную поддержку и производительность на устройствах конечных клиентов (когда каждый раз «внезапно» оказывается, что средний домашний и офисный компьютер — это не десктоп с i7, 32 ГБ ОЗУ, 27-дюймовым монитором и последними версиями всего ПО). Впрочем, это всё банальные проблемы, которые так или иначе потом можно решить, хотя они и бесят, когда одни и те же люди умудряются регулярно попадать в них раз за разом и не делать выводов.
Куда опаснее ситуации, когда проектом руководит заказчик. Да-да, в этой ситуации все ещё хуже. Нет, заказчик не знает, чего он хочет. Нет, заказчик не «лучше знает», что ему нужно. Заказчик может потенциально знать цель проекта, его потенциальную аудиторию и особенности своего бизнеса, но он гарантированно не знает, как именно для этого должен быть сделан проект, чтобы он был хорошим, удобным, успешным и работающим. Честь и хвала тем людям, которые честно себе признаются, что они не являются специалистами в разработке, и доверяются специалистам, лишь общаясь с ними и обговаривая различные варианты реализации и всякие мелкие детали, однако это, к сожалению, очень редкое исключение. Почти всегда, когда проектом так или иначе рулит заказчик, всё происходит совсем иначе, и разработка превращается в ад.
Свистелки и перделки? Господи, да ведь именно заказчики в первую очередь и просят весь этот бред! Дурной вкус, желание выделиться, понты — объясняйте как хотите, но именно заказчики в первую очередь тянут подобное в проект. Нестандартные, выдуманные ими сами и абсолютно неинтуитивные/нелогичные элементы управления, меню, схемы поведения — шедевры креатива заказчиков. Рахитичные дизайны, кривые схемы вёрстки, цветовые схемы для инопланетян, несочетаемые шрифты, дикие пиктограммы, переусложнённые формы, бессмысленные анимации и прочее «добро» — это как раз результаты прямого доступа заказчика к руководству проектом. Про постоянные смены настроений, идей и многократные переделки уже сделанного я вообще молчу — да, кому-то такое нравится, вот только сроки сдачи проекта таким образом могут сдвигаться почти вечность. В итоге то, что можно было сделать, протестировать и сдать за три-шесть месяцев, делается более двух лет. Я не знаю, каким надо быть мазохистом, чтобы разработчику нравилось участвовать в этом балагане, даже получая за это приличные деньги.
А разгадка проста: менеджер, как руководитель проекта, играет роль фильтра между процессом разработки и заказчиком. Заказчиком, которому менеджер объясняет и рассказывает, что хорошо, а что плохо, что стоит делать, а чего делать не стоит, объясняет последствия для проекта в случае реализации тех или иных идей и фич — в общем, при общении с заказчиком менеджер как раз таки старается, чтобы проект получился нормальный, удобный, современный, актуальный, а главное, его можно было сделать в адекватные сроки и побыстрее успешно сдать. Преуменьшать этот труд можно либо по глупости, либо по наивности или максимализму.
По моему личному опыту разработки, в котором были самые разные проекты как по тематикам, так и по размерам, менеджеры — это как раз тот элемент работы, благодаря которому проекты в итоге успешно сдаются и получаются нормальными. А вот проблемы начинаются как раз тогда, когда за руководство проектом садятся разработчики, любящие гнуть пальцы на тему того, какие они крутые специалисты по всему, или, что ещё хуже, когда проектом руководит сам заказчик (или его представитель), в большинстве которых сразу просыпается «творческая личность», начинающая выдумывать такой бред, который многим даже и не снился.
О проектах, ведомых разработчиками, можно долго рассказывать, но чаще всего там всё довольно-таки прозаично и упирается в неадекватные шапкозакидательские оценки сроков исполнения, абсолютно ублюдочную проработку интерфейсов, логики работы и юзабилити (ведь это всё «не нужно», «тут всё ясно и дебилу»
Куда опаснее ситуации, когда проектом руководит заказчик. Да-да, в этой ситуации все ещё хуже. Нет, заказчик не знает, чего он хочет. Нет, заказчик не «лучше знает», что ему нужно. Заказчик может потенциально знать цель проекта, его потенциальную аудиторию и особенности своего бизнеса, но он гарантированно не знает, как именно для этого должен быть сделан проект, чтобы он был хорошим, удобным, успешным и работающим. Честь и хвала тем людям, которые честно себе признаются, что они не являются специалистами в разработке, и доверяются специалистам, лишь общаясь с ними и обговаривая различные варианты реализации и всякие мелкие детали, однако это, к сожалению, очень редкое исключение. Почти всегда, когда проектом так или иначе рулит заказчик, всё происходит совсем иначе, и разработка превращается в ад.
Свистелки и перделки? Господи, да ведь именно заказчики в первую очередь и просят весь этот бред! Дурной вкус, желание выделиться, понты — объясняйте как хотите, но именно заказчики в первую очередь тянут подобное в проект. Нестандартные, выдуманные ими сами и абсолютно неинтуитивные/нелогичные элементы управления, меню, схемы поведения — шедевры креатива заказчиков. Рахитичные дизайны, кривые схемы вёрстки, цветовые схемы для инопланетян, несочетаемые шрифты, дикие пиктограммы, переусложнённые формы, бессмысленные анимации и прочее «добро» — это как раз результаты прямого доступа заказчика к руководству проектом. Про постоянные смены настроений, идей и многократные переделки уже сделанного я вообще молчу — да, кому-то такое нравится, вот только сроки сдачи проекта таким образом могут сдвигаться почти вечность. В итоге то, что можно было сделать, протестировать и сдать за три-шесть месяцев, делается более двух лет. Я не знаю, каким надо быть мазохистом, чтобы разработчику нравилось участвовать в этом балагане, даже получая за это приличные деньги.
А разгадка проста: менеджер, как руководитель проекта, играет роль фильтра между процессом разработки и заказчиком. Заказчиком, которому менеджер объясняет и рассказывает, что хорошо, а что плохо, что стоит делать, а чего делать не стоит, объясняет последствия для проекта в случае реализации тех или иных идей и фич — в общем, при общении с заказчиком менеджер как раз таки старается, чтобы проект получился нормальный, удобный, современный, актуальный, а главное, его можно было сделать в адекватные сроки и побыстрее успешно сдать. Преуменьшать этот труд можно либо по глупости, либо по наивности или максимализму.