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 недели”

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

В чем мораль?

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

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

Недавно я получил очень интересный комментарий на свой пост “Лучший способ найти время на юнит-тесты”:

Ты не рассмотрел одного аспекта. Ты и твоя команда разработчиков - не монополисты. Вы в ситуации рыночной конкуренции. И в этом смысле сроки, за которые вы поставляете заказчику продукт - один из тех показателей, в том числе и по которому вас будут выбирать из множества других. Хорошо, когда заказчик “повязан” на вас. А если нет? Если вы вынуждены конкурировать с другими, с тем чтобы “пробить” под себя заказ? При этом, как правильно ты заметил, необходимость документирования и тестирования заказчика не волнует (первое - как правило, второе - всегда). Его волнует конечный продукт, а также сроки и цена (которая, в свою очередь, тоже не склонна снижаться с ходом тестирования и документирования; ты же тоже, при всём понимании необходимости некоторых вещей подобно этой, не альтруист). То есть: ты не можешь сказать, чем обусловлены бОльшие сроки (по сравнению со среднерыночными или сроками реализации проекта отдельными ушлыми псевдо-разработчиками), за которые твоя команда берётся реализовать проект. То есть можешь, но это никого не интересует. И это становится не положительной, позитивно характеризующей вашу разработку стороной, а наоборот - вашим конкурентным недостатком. Это IMHO. Уверен, мОгущее иметь место в современном бизнес-мире. Антон С. (ТАУ, 2001-2006)

Что я думаю по этому поводу?

У компаний, занимающихся установкой пластиковых окон, есть два основных источника дохода. Первый источник - это заказы на остекление новостроек. Что нужно, чтобы преуспеть на этом рынке? В первую очередь - цена. Заказы на остекление новостроек распределяются либо по знакомым, либо через тендер. Чтобы выиграть тендер, нужно предложить самый дешевый вариант. Или предложить самый большой откат - в этом случае абсолютно так же нужно минимизировать основную стоимость. Таким образом, в новостройки, как правило, ставят самые дешевые окна, подходящие под установленный строительной компанией стандарт. Второй источник дохода - установка окон отдельным людям. Здесь клиента в первую очередь волнует качество и уровень обслуживания, и клиент готов за это платить. В отличие от примера с новостройкой, клиент ощутит последствия выбора на своей собственной шкуре, а не только на своем бюджете.

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

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

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

У меня нет желания работать на этом рынке. Я не для того пытаюсь собрать отличную команду разработчиков, найти лучшие возможные инструменты и создать идеальный процесс разработки, чтобы пытаться конкурировать за проекты, где это не нужно. Это не наш рынок и он никогда не будет нашим. Пусть им занимаются люди, у которых есть нужные связи и умение “впарить” проект заказчику.

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

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

• Джоэль Спольски, “Пять миров”.
• Джоэль Спольски, “Верблюды и песочница”.
• Эрик Синк, “Closing the Gap, part 2 (Responsive Sales)”.
• Эрик Синк, “How to get people talking about your product”.
• Эрик Синк, “Choose your competition”.