Школа
Дизайн

Программисты просят: «принесите макеты»

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

Аргументированного ответа на вопрос, как составить совместный план разработки, не имея макетов, у меня нет.

Соответственно, мы скатываемся к тому, что сначала две недели пилим макеты, потом передаём программистам. Сами того не хотя отходим на второй план. Дизайнерские решения начинают принимать программисты. Мы пишем баг‑листы.

Как быть? Или, может, я что‑то не так понимаю?

Лёша Рева
19 фев 2015
👁 1544   🗩4
Дизайн

Программисты просят: «принесите макеты»

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

Аргументированного ответа на вопрос, как составить совместный план разработки, не имея макетов, у меня нет.

Соответственно, мы скатываемся к тому, что сначала две недели пилим макеты, потом передаём программистам. Сами того не хотя отходим на второй план. Дизайнерские решения начинают принимать программисты. Мы пишем баг‑листы.

Как быть? Или, может, я что‑то не так понимаю?

Лёша Рева
19 фев 2015
👁 1544   🗩4
Николай Товеровский
Директор, автор курса «Управление проектами, людьми и собой»
Полезно
 4
4
Непонятно
  
Войдите в Бюросферу, чтобы голосовать

Лёша!

Просьбу сначала принести макеты я слышу постоянно. Такая просьба логична: не видя дизайн, разработчику сложно оценить объём работы: «Вообще не представляешь, что делать придётся». Давать невыполнимые обещания никто не любит.

Недостаток «каскадной модели», когда разработчики ждут дизайн, не в том, что дизайнер отходит на второй план. Участие дизайнера в разработке зависит от договорённостей о дизайнерском управлении разработкой. Проблема в потере времени и фичеризме: сначала программисты простаивают, дожидаясь дизайна, затем, участники проекта стремятся реализовать все придуманные фичи. Фиксированного дедлайна в этот момент ещё нет, и добавить недельку не страшно. Проект раздувается, как воздушный шарик.

Чтобы договориться, я объясняю программистам пользу фиксации дедлайнов: если дизайнер придумает фичу, которую будет невозможно реализовать в запланированный срок, её пофлексят. И, конечно, головную боль разработчиков снимают спецификации, которые они готовят, получив дизайн. Спецификации позволяют «поженить» дизайн с реальностью в середине проекта, принять решение о флексе. Спецификация — это и есть ТЗ, которое так хотят разработчики, но появляется она, когда о проекте уже многое известно.

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

Вне бюро я также столкнулся с проблемой «сначала нарисуйте». Но без сильного желания клиента работать именно со мной показать пользу планирования итерации до начала работы оказалось гораздо сложнее.

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

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

В результате дизайнер и разработчик пилят продукт, а не спорят.

У меня пока недостаточно информации для оценки идеи. Я знаю только, что клиенту мой подход понравился.

P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.

Полезно
 4
4
Непонятно
  
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

Корень зла в том, что разработчики, которых приводит клиент, зависимы от вас. Соглашаясь с вашим планом работ, они берут на себя большие риски. Попробуйте поставить себя на их место. «Ребята, нам нужно будет спроектировать сайт. Пока не можем сказать, что за сайт, и какие возможности, но всё должно быть готово за три недели». А что если вы не сможете пофлексить часть задач? Если затянутся переговоры и согласования? Убытки от всех этих ситуаций будете нести не только вы, но и они.

Отказ разработчиков — это защитная реакция. Нужно понять их тревогу и постараться её развеять. Возможно, помогут рекомендации другой команды разработчиков, с которыми удачно поработали. Или клиентов, с которыми удалось сдать подобный проект в срок. Трёхсторонняя встреча, где вы вместе с клиентом согласуете принципы работы, использование ФФФ.

Любые уговоры бессмысленны. Покажите на деле, что это безопасно.

Требовать финальные макеты для оценки программирования — это, конечно, перегиб.
Но как минимум черновые функциональные прототипы — это не просто нормально, это обязательно.

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

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

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

Цель рубрики — обсуждение вопросов дизайна, веб-разработки, переговоров, редактуры и управления.
Комментарии модерируются. Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры.

Рекомендуем другие советы