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

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

В чем мораль?

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

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

Где-то с месяц назад наткнулся на пост Why learning Haskell/Python makes you a worse programmer. Люк Плант (Luke Plant) поднимает крайне актуальную для многих из нас проблему — изучение продвинутых языков не делает вас лучшим программистом на том, что приходится использовать, а, напротив, деморализует и снижает качество работы.

Точка зрения сотрудника

Очень рекомендую прочитать как статью, так и комментарии. Если кратко, приводятся два основных аргумента:

1. После того, как ты понял и полюбил Python, писать на C# неприятно. Код громоздок и некрасив. Процедурный подход вызывает кучу потенциальных глюков. Кроме того, начав думать на Python, приходится работать “живым компилятором”, переводя эти мысли в C#.

2. Начав использовать функциональное программирование, пытаешься использовать его везде где только можно. C# не поддерживает многие концепции функционального программирования, в результате чего попытки применять функциональный стиль выглядят уродливо и непонятно. Многие задачи проще решать процедурно.

Люк делает вывод, что нет смысла заниматься самосовершенствованием, если потом не сможешь использовать обретенные навыки.

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

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

Добавлю еще, что все относительно. Можно заменить языки в обсуждаемом примере на другие, но проблема останется той же. Есть языки лучше, чем Python и Haskell, есть и множество языков, куда хуже C#. В реальной жизни все еще сложнее, потому что важно не столько качество языка, сколько пригодность его и связанной с ним платформы для решения конкретной задачи.

Точка зрения компании

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

Ряд задач требуют использования неоптимальных с точки зрения эстетики и уровня абстракции языков. Драйвера и embedded-приложения пишутся на C. Windows-приложения — на том, что поставляет в данный момент Microsoft (сейчас это C#). SAP кастомизируется с помощью ABAP, недалеко ушедшего в своем развитии от COBOL. Можете продолжать до бесконечности.

Кроме того, есть ниши, где выбор языка может повлиять на маркетинговую привлекательность продукта. Java продается. C# продается. Hashkell… — а что это такое? Думаю, логика выбора языка в таком случае будет очевидна.

Что думаете по этому поводу, коллеги?