Outsourcing stories

Небольшая зарисовка из трудовых будней

Вводная

Клиент: “Алекс, не мог бы ты посмотреть спецификацию проекта Х? Можешь ли ты это сделать и сколько приблизительно времени это займет?”

Я: “ОК, я так понимаю это высший приоритет на сейчас”

Клиент: “Да”

Я: “Что ж, тогда поехали… Скоро вернусь”

Читаем спецификацию

Открываю Basecamp, иду на страницу проекта. Имеется: один абзац общих требований и приаттаченый Word’овский файл. Скачиваю. Открываю. 5 страниц, на первой общие требования и предполагаемый план работ, на остальных четырех — описание функций в виде эскизов страниц с описанием.

Смотрю на расписание. Три контрольных точки:

• 0-30% done “Complete design and markup of all presentation layers” плюс какой-то минорный функционал. Target Completion Date: через 3 дня

• 30-70% done Весь функционал, включая биллинг и прием платежей. Target Completion Date: через 10 дней

• all done Тестирование и доводка согласно пожеланиям заказчика. Target Completion Date: через 25 дней

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

Бегло просматриваю страницы с функционалом. Похоже, это главные страницы основных секций проекта. Относительно подробное описание функций есть в комментариях справа. wiki, блоги, теги, комментарии, чаты, зоны видимости сообщений — черт, сколько умных слов-то…

Делаем estimate

Возвращаюсь к началу описания функционала. Достаю планшет и чистый лист бумаги. Начинаю медленно читать список функций и сразу же набрасываю модель данных — имена объектов (сущностей) и связи между ними. Связи «многие ко многим» не детализирую. Кардинальность связей бросаю обозначать на пятой сущности — потом разберемся, если еще понадобится. Заканчиваю первую страницу с функционалом — в активе 7 сущностей. После следующей страницы – еще 6, да и связей прибавилось…

После последней страницы у меня уже 19 основных сущностей. Можно предположить, что второстепенных сущностей будет, как минимум, столько же, если не вдвое больше. Отдельно выписываю особо запомнившиеся фрагменты функционала: биллинг, прием платежей, live preview закачанных пользователями видеороликов и т.д.

По грубой прикидке, каждой сущности будет соответствовать класс модели. На каждый класс придется несколько сотен строк кода (Ruby on Rails). И еще на столько же потянут тесты. В общем, уже понятно, о чем говорить клиенту:

Я: “Закончил читать спецификацию. На реализацию уйдет заметно больше 6 месяцев при команде в 4 человека”. Насколько больше — предсказать за полчаса невозможно, да и, учитывая указанные в документе контрольные точки, едва ли будет интересно заказчику.

Клиент: “Ладно, забудь. Можешь прекратить читать. Я знаю парня, который сделает это за 4 недели”

Я: “Что ж, удачи ему. Я не верю, что это возможно”

В чем мораль?

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

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

В одном из недавних комментариев Андрей написал о наболевшем:

И, наверное, документирование надо рассматривать как еще одну _невключаемую_обычно_ в план работ задачу.

“У нас нет времени писать юнит-тесты. Сделаете это потом”. Звучит знакомо, не правда ли? Попав в ситуацию дефицита времени, сложно бороться с искушением сэкономить время за счет юнит-тестов, ревью, документации, любой другой работы, которая вроде бы не обязательна для получения работающего кода. Что ж, многие и не борются с искушением, а смело срезают углы. Думаю, не надо объяснять, почему это плохая идея. На следующем же проекте, наученные горьким опытом, разработчики будут понимать истинную цену такой “экономии”.

Но что же делать, если сэкономить время на необходимых работах хочет ваш заказчик? Это гораздо более неприятная ситуация. В срыве сроков и плохом качестве виновата будет все равно ваша команда. Да и заказчики реже учатся на своих ошибках, чем разработчики.

Убедить типичного заказчика в необходимости юнит-тестов практически невозможно. Поэтому не стоит и пытаться этого делать. Хотите найти время на юнит-тесты, code review и документацию - сделайте эти задачами обязательными этапами разработки любой новой функции. И не говорите о них вашему руководству или заказчику. Никогда. Просто включайте дополнительное время в оценку трудоемкости разработки основных функций.

В статье “Секрет Айсберга” Джоэль Спольски приводит отличный пример на эту тему:

Когда клиент или нетехнический менеджер очень хочет принять участие в проекте, дайте ему несколько версий графического дизайна, чтобы они могли выбрать. Меняйте расположение некоторых вещей, изменяйте вид, шрифты, двигайте логотип, делайте его то больше, то меньше. Дайте им почувствовать себя важными, предоставляя возможность поиграть с малозначимыми вещами. В этом случае они не нанесут вреда срокам. Хороший дизайнер интерьера постоянно приносит эскизы клиенту и вещи, из которых он может выбрать. Но они никогда не обсуждают с клиентом расположение умывальника. Он находится рядом с канализационной трубой и не важно, чего хочет клиент. Нет смысла тратить время на обсуждения, где должен находится умывальник - он должен быть рядом с трубой, даже не начинайте разговор об этом; пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.

Отличный совет. То же самое нужно делать с процессом разработки. Готовый код должен быть покрыт тестами, отрецензирован и документирован. Не важно чего хочет ваш руководитель или заказчик. Если он не эксперт по процессу разработки ПО, то у него нет права голоса.

Разумеется, будет непросто создать и поддерживать подобную ситуацию, а особенно не испортить при этом отношения со спонсором проекта (что гораздо опаснее, чем разрабатывать продукт без юнит-тестов). Но если вы менеджер проекта, то это, черт побери, ваша работа. Займитесь ей, а не пытайтесь выжать из программистов рекордную производительность.

Материалы по теме:

• Перевод статьи Дэйва Томаса и Энди Ханта “Учимся любить юнит-тесты”. В ней, помимо прочего, авторы проехались катком по аргументу “У нас нет времени, чтобы писать тесты”