Раскрыть меню
Изнанка IT-сферы
Юлия Садыхова-Котова, руководитель проекта Kwork.ru

В разнообразных IT услугах на разовой или регулярной основе нуждается уже абсолютно любой бизнес. И если потребности в системном администраторе традиционно закрываются штатной единицей, то с разработчиками, например, уже не все так однозначно. Постараемся приоткрыть завесу тайны: что происходит внутри поставщика IT услуг, которому поступает свежий заказ, и почему им в итоге заняты совершенно посторонние люди и организации. Откуда берутся многозвенные цепочки посредников и куда уходят ваши деньги.
Этап 1: Поиск подрядчика
Что хочет достичь заказчик
При выборе подрядчика любой владелец бизнеса пытается найти "горячий лед" - сочетание минимальной стоимости работ при максимально качественном результате. Самые низкие цены по рынку ожидаемо дают перекупщики всех сортов и мастей.

Риск: у подрядчика не хватит сил или опыта закончить ваш проект
Кроме перекупщиков и фантомных студий на рынке всегда есть огромное количество новичков, готовых демпинговать практически без ограничений, чтобы получить себе хотя бы первого клиента. Казалось бы, идеальная ситуация: взялись за работу за копейки, а делать ради хорошего отзыва будут хорошо? Не все так просто… Чаще всего новичок даже не уверен, сможет ли он вообще выполнить заказ. Но он попробует, можете быть уверены.
Неопытный подрядчик объясняет клиенту, почему опять все не так.
Решение: не отдавайте новичкам большие проекты. Попробуйте заказать модуль будущего продукта или отдельный этап конкретных работ. Вы увидите, насколько исполнитель с этим справится.

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

Именно на этом этапе, погнавшись за ценой и обещаниями, вы с большим риском доверяете свой заказ "IT-галере".

Галера выглядит примерно так:
Изображение с сайта caricatura.ru
Чтобы заказчику было понятнее, о чем речь, попросим рассказать о "галерах" человека, прошедшего полный путь от "гребца" до "капитана":

Главный и незыблемый принцип галеры: «ты начальник — я дyрак, я начальник — ты дyрак». Если галера приплыла малость не туда и продукт не соотносится с желаниями заказчика вообще никак, то виноваты конечно гребцы (рядовые программисты). Гребцы бубнят тихо под нос: «Куда показывали — туда и приплыли». Хотя конечно возражать не хочется, — за возражения могут и за борт. Приходится быстренько выгребать куда велено (по вечерам, ночам и в выходные). Это называется овертайм. Молодой неопытный гребец по недомыслию может спросить у погонщика: «а почему так часто овертаймы? Труд же должен оплачиваться?». Молчание будет ему ответом...

Я думаю, вы уже догадались, какую часть души вложат в ваш продукт разработчики, работающие в подобных условиях.
При этом клиентское обслуживание в "галерах" всегда на высоте, а аккаунт менеджеры дружелюбны, услужливы и обходительны:

Клиент галеры обеспечивается высококачественным обслуживанием. Искусство менеджера состоит в формировании у клиента особого шаблона, в котором он (клиент) — VIP — существо особенной важности. Похаживая по палубе, менеджер поясняет клиенту, как тому повезло, что именно эта компания оказывает ему услуги. «Мы отбираем лучших из лучших, там»… менеджер делает размашистый жест вдаль за борт, «там стоит очередь желающих у нас работать. У нас вышколенный персонал».

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

Риск: отсутствие контроля над проектом. До самого релиза.

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

Решение: Еще до старта обсудите, как вы будете взаимодействовать, а также методы, которые будут использоваться при реализации проекта. Требуйте полной прозрачности процесса, включая следование пунктам плана и соблюдение дедлайнов. Как у клиента, у вас должен быть доступ ко всем рабочим материалам.

Впрочем, сколько не пытайтесь найти хорошего подрядчика, с вероятностью в 95% промажете. Статистика подтверждает, типовая комплексная задача в e-commerce решается с 3-4 захода (и исполнителя соответственно).
Обобщенная статистика агентства по интернет-рекламе
Что делать? Обзавестись хотя бы минимальными компетенциями, либо нанять того, кто ими обладает для сопровождения сделки. Или же смотреть в сторону in-house разработки, со всеми вытекающими.


Этап 2: ТЗ и сроки

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

Здесь важно понимать, что позиция заказчика всегда выглядит примерно так: "Зачем специально отражать незначительные моменты в ТЗ, это же совершенно очевидно". Позиция исполнителя же выглядит так: "В ТЗ сказано: разместить кнопку. Что она должна делать - не написано. Делаем по ТЗ". В итоге кнопка есть, но она ничего не делает, а заказчик с исполнителем начинают ожесточенный спор, кто в этом виноват.

На этом этапе роль мостика выполняет руководитель проекта - человек, который владеет двумя языками: деловым русским и "языком разработчиков". Обычно руководитель проекта находится на стороне подрядчика, что усугубляет перекос компетенций. И еще между вами и РП есть испорченный телефон в лице аккаунт-менеджера.

Согласование сроков разработки - вопрос отдельный и чаще всего он выглядит вот так:
Изображение с сайта habr.com
Что делать? Убедитесь, что вы хотя бы с руководителем проекта разговариваете на одном языке. Как в плане постановки задач, так и в расчете сроков. Используйте для разработки ТЗ костыли наподобие "user stories", поможет сократить сроки. Если не можете составить их сами - нанимайте специалиста. РП на неделю к себе в команду, да.


Этап 3: Разработка

А вот здесь начинается самое интересное. Предположим, случилось чудо и вы с первого раза попали на адекватную (хотя бы внешне) IT-студию и даже умудрились согласовать ТЗ быстрее, чем за полгода. Студия берется за работу. В ней есть, предположим, 1 тимлид, 2 разработчика уровня senior, 4-5 middle'ов и пара десятков junior (возможно, вам их даже показали). В мечтах заказчика вся эта команда слаженно берется за работу и делает красивый, цельный, задокументированный проект примерно месяца за два.

А теперь расскажем, что происходит в реальности. У студии в работе уже 18 проектов, из них 3 с безбожно сорванными дедлайнами (на грани отказа клиента), 5 на финальной стадии (с бесконечными мелкими правками), а оставшиеся 10 на разных стадиях готовности.

Тимлид сидит с больной головой и занимается уже исключительно раскидыванием обязанностей под прессом своих же аккаунт-менеджеров. Оба senior'а разрываются между ключевыми задачами заказчиков и работой над пилотным проектом самой студии, который захотел лично директор. Middle'ы не знают куда податься: то ли помогать senior'ам, то ли контролировать работу jumior'ов, то ли заняться наконец документированием всех 18 проектов, до которого руки еще не дошли ни у кого.

Junior'ы… а что junior'ы? В отсутствии внятно поставленных задач (всем не до них) они творят некий код. Если звезды сошлись удачно, сотворенный разными джунами код впоследствии можно будет собрать в подобие рабочего модуля и этот модуль случайно окажется именно тем, что хотел хотя бы один клиент из восемнадцати. Если нет - люди просто получат свой оклад, а в следующем месяце (когда хоть кто-то спохватится и даст им четкие задачи) начнут писать нужный код. Потом выяснится, что клиент устал ждать и заказал этот модуль на стороне и этот код менеджеры будут пытаться продать другому клиенту, для чего его нужно будет адаптировать.

Конечно мы сознательно усугубили описание ситуации. Однако в профессиональной среде об этой проблеме известно давно. На Хабре масса профильных обсуждений. Программисты размышляют на тему "Почему мы пропускаем дедлайны, и как с этим бороться". Руководители делятся опытом "Как подсознательно побудить сотрудников соблюдать дедлайны проекта"

Впрочем, чему удивляться, если для менеджеров проектов пишут вот такие вредные советы:

Вас не должны любить! Любовь — это лишнее в современном жестоком мире. Вас должны бояться, обсуждать, на вас должны работать. Не просто работать, а пахать от ночи до зари! И запомните: центр креатива — это вы. Только вам решать, что должно быть в проекте. Все комментарии и исправления заведомо признавайте как унылое... просто плохую идею

Источник: https://career.ru/article/10945

Если у подрядчика руководитель проекта и разработчики стоят по разную сторону баррикады, продуктивной работы не будет никогда. Шанс получить в этой студии свой заказ вовремя и в соответствии с ТЗ вы уже представили, правда?

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


Этап 4: Получение результата
Сроки сорваны, проект не готов.

Если хотите получить достоверную статистику сорванных дедлайнов - спрашивайте не у менеджеров, а у разработчиков. А они ответят, что если студия не использует Agile-подход в разработке, то проваливаются сроки реализации четырех задач из пяти, а если использует, то примерно двух-трех из пяти. С учетом того, что в проекте задач не одна и не две, то общий дедлайн срывается почти всегда.

Вы начинаете нервничать и отправляете ключевого сотрудника разобраться с ситуацией. Встречи с аккаунт-менеджерами студии становятся вдвое чаще, а их улыбки втрое шире. Вас уверяют, что проект "вот-вот". Спустя два месяца "вот-вотов" вам показывают некий функционал. В лучшем случае он примерно похож на то, что было прописано в ТЗ и охватывает процентов двадцать ваших пожеланий. Но проект, готовый на 20% для вас бесполезен на все 100 - вы не можете начать работу с клиентами, пока он не готов.

И вот наступает момент Х: вы не можете больше ждать и уведомляете студию о готовности отказаться от их услуг, если они не закончат проект за месяц. Вашим вопросом занимается лично директор студии и берет дело "на особый контроль". Смотрим, что происходит внутри студии в этот момент.
А внутри студии совещание. Директор (недоволен), аккаунт-менеджеры (улыбки еще не отклеились от лица), тимлид (пытается изобразить, что он не спит):

- Д: Клиент реально готов отвалиться?
- А: К сожалению да, мой господин.
- Д: Тимлид, тебя пора повесить.
- Т: Да, господин, пора. Хоть на виселице отдохну.
- Д: Тимлид, есть шанс завершить проект за месяц?
- Т: Только если забросить остальные, мой господин.
- Д: Мы можем забросить остальные?
- А: Нет, мой господин. Уйдут и денег не заплатят.
- Д: Хорошо. Отчаянные времена требуют отчаянных мер. Тимлид!
- Т: Да, мой господин?
- Д: Разбей ТЗ на блоки и все, что еще не готово сливай на фриланс!
- Т: Опять?
- Д: Снова!

Не верится? А они не только именно так и работают, но и рекомендуют внедрять этот подход): "Как организовать работу веб-студии, если заказов стало слишком много"

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

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

Из дебрей комментариев weblancer.net

Ну что вы как маленькие? Если видите сложный заказ с горящими сроками и низкой оплатой - это 100% студия. Оплата низкая, потому что деньги клиента они уже проели, а сроки - у них самих горит, если уже не сгорело. Если других заказов нет - берите эти и надейтесь, что когда-нибудь сумеете выйти на прямых заказчиков.

Из обсуждения на https://www.facebook.com/jff.name/


Финал

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

Мораль: может быть, стоит подумать и обратиться к Васе с самого начала?

Откроем секрет - фрилансеры и сами мечтают получать прямые заказы, а не горящее ТЗ с очередной тонущей "галеры". Пора пойти им навстречу, как считаете?


Выскажите свое мнение: