Лёша Рева
19 февраля 2015
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

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

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

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

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


Лёша!

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

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

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

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

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

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

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

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

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

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

P. P. S. Я проведу практический курс «Управление проектами, людьми и собой» 10, 11 и 12 июня в Москве

 

Запись открыта до ВС 4 июня


Поделиться

Комментарии

Маргарита Марянян
19 февраля 2015

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

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

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

Дмитрий Кравчик
19 февраля 2015

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

Дмитрий Кравчик
26 февраля 2015

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

Денис Братчук
20 февраля 2015

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

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Недавно всплыло

Расскажите об управляемости: программа 2 1 4 2