Сторона заказчика или "трудно быть богом"
Итак, вы хотите разработку — хотите создать какой-то софт. Скорее всего вы относительно молоды, поэтому точно имеете определенный опыт работы с компьютером, хотя-бы с офисным и видеоиграми. Рассказываю что вам нужно знать, чтобы «ваше очко не ушло в зрительный зал» и все получилось.
Кто все это пишет
Конечно же до того как начать предоставлять услуги по разработке софта, я и сам много лет работал в найме, в штате крупных компаний.
И точно также решал задачу поиска адекватных исполнителей и подрядчиков, которым можно доверить вантуз и ершик реализацию проекта.
В разных случаях, в разных ситуациях и с проектами разного масштаба.
Работал как с фрилансерами так и с крупными подрядчиками — вообщем прекрасно понимаю проблематику и доступные варианты.
А те кто вдруг меня вспомнят — накатите по стопке за былые времена, благо что мне самому больше пить нельзя.
Исторический экскурс
Начну издалека — с небольшого исторического экскурса.
Расскажу как все это присходило в нашем совсем недавнем прошлом, но чтобы не «растекаться мыслью по древу» — ограничусь историей заказной разработки только в РФ, которая сильно короче чем мировая.
Итак, представьте что на дворе 1992й год, вы — директор «средне-крупного» предприятия, условного «вентиляторного завода». Компьютеры у вас уже есть, c каким-нибудь MS-DOS, а вот софта толком нет.
А задачи автоматизации все те же самые что и сегодня:
отчеты, расчеты и списки клиентов.
И вот вы приезжаете в Москву, начинаете искать кто бы вам смог чего-то написать, начинаете искать программистов и... их нет.
Ну вернее они конечно есть, но вас к ним не пустят, поскольку сидят они по всяким бывшим НИИ с работой у них все хорошо.
Вообщем до начала 2000х заказной разработки для внутреннего рынка РФ фактически не было, а весь период 90х был про продажу готовых ИТ-продуктов. И вы шли в магазин, обычный оффлайновый и покупали например 1С на дискетах. Точно также как тогда покупали видеоигры.
Far, WinRAR — примеры такого софта из тех времен.
В те времена все кто хоть как-то умел писать софт — им и владели, его продавали и сами собирали прибыль.
Самой концепции «разработки на заказ» просто не было, поскольку программистов было слишком мало, единицы среди единиц владеющих компьютером.
Дальше, счастливые 2000е — золотое время аутсорса на Запад.
500 баксов зарплаты в конверте вчерашнему студенту, $30/час рейт для Джона из Техаса — вот на эту разницу и создавались современные Ланиты с Кроками, даже если их современная корпоративная история это отрицает.
Хорошие были времена, жалко кончились.
Современная заказная разработка
На данный момент в РФ примерно 75% рынка заказной разработки это госзаказ и гос.проекты в том или ином виде.
конские размеры типичного проекта в стиле «у нас в Техасе все большое» и скажем так «неспешность исполнения».
Вообщем, в нынешних реалиях, типичный аутсорсер-разработчик ПО это компания 100+ человек, большую часть времени неспешно занимающаяся госпроектами.
Это не обязательно прямое участие в тендерах по 44ФЗ, гораздо чаще это субподряд. А сами проекты — не обязательно для B2G сектора, это может быть и банки и телеком и ритейл.
Просто оно сейчас все фактически только крупное, поэтому имеет «легкий налет государственности», даже если государство формально не имеет никакого отношения к компании.
Типичный современный программный проект — аморфное нечто, создаваемое годами и постоянно переписываемое и доделываемое, часто непонятно зачем.
Официально конечно есть и название и предназначение и вроде даже пользователи, но только «запашок говнеца» от него ничем не перебьешь.
А типичный брифинг для новых лиц на проекте стабильно и везде теперь называется «погружение», причем погрузиться предлагают отнюдь не в кадку с цветами.
Вот в таких реалиях современной разработки вам придется работать и получать хоть как-то результат.
Лично вы, ваши силы и возможности
Катаетесь на ч0рном гелике по встречной и разворачиваетесь через двойную сплошную? Есть связи в «органах» и администрации? Таскаете кэш чемоданами, попутно катая дороги белого?
Увы но это все детский лепет, фигня и понты по сравнению с отлаженным бизнесом по разработке ПО.
Мелкая команда разработки из 6 человек в белую стоит примерно $500к в год на один только ФОТ (фонд оплаты труда). В конвертах айтишники зарплату получать больше не хотят, увы.
~$500к одних только чистых затрат в год лишь на зарплату, для самой мелкой команды разработки из возможных.
А у типичной российской компании-аутсорсера сейчас штат в 100+ рыл и железные «длинные» контракты.
Вообщем дверь пинком вам открывать никто не даст и на колени перед вами не упадет, если вдруг была такая мысль.
Поэтому самый первый и самый важный совет:
Это вообще по-жизни важно, не только в случае заказа софта.
Не надо заходить с вашей любимой позиции «клиент всегда прав» — обосретесь, с гарантией.
Владельцы даже средних компаний-аутсорсеров — давно не карикатурные ботаники-задроты, а вполне себе серьезные бизнесмены с постоянными и ежедневными рабочими контактами с государством.
Поэтому давить, угрожать и пытаться кинуть (как вы любите делать с гастробайтерами-строителями) — не получится.
Правильный выбор
Я уже частично раскрывал тему выбора правильного подрядчика, если лень читать то в кратце:
ни предыдущий успешный опыт c этим конкретным подрядчиком, ни репутация и реализованные проекты, ни список клиентов и партнеров компании — не являются 100% гарантией успеха именно вашего проекта.
Если выбранная компания-разработчик крутая, а вы — пока нет, то скорее всего вас (как клиента) просто перепродадут субподрядчику, причем даже не поставив в известность. Ну или просто откажутся — оба варианта являются нормой для этой отрасли.
Если же все наоборот и вы без реального опыта, выступаете со стороны крутого и богатого заказчика — вам п#здец.
Конечно не вам лично, а вашей карьере в этой крутой и богатой компании.
Это очень плохая идея — без опыта и с деньгами лезтьв кадку с акуламина рынок аутсорса, чтобы сделать какой-то большой проект.
Лучше старших товарищей попросите помочь — целее будете.
РФ — не Запад, у нас тут нет западных ценностей, западного делового этикета и принципов ведения бизнеса.
Если вы находитесь США, ничего не знаете о разработке ПО но у вас есть пара миллионов долларов — у вас будет работающий софт.
Конечно вас немного на#бут, как новичок заплатите чуть дороже — но результат все равно получите.
Если вы в РФ в тех же обстоятельствах — вас выдоят и высушат подчистую, а получите вы целое ведро н#хуя.
Поэтому если нет опыта совсем — лучше не лезьте лично, найдите опытного менеджера, который пойдет с вами на переговоры.
Вообщем дальше исходим из того, что вы не вчерашний студент и уже есть какой-то жизненный опыт: ведение переговоров, управление сотрудниками и финансы.
Теперь вам нужно выбрать с кем работать.
Ключевой фактор
Мой опыт показывает что ключевым фактором для нормальных деловых отношений в целом и для хорошего результата работ в частности является обоюдный интерес.
Как подрядчику должен быть интересен ваш проект так и вам самому. Без этого не взлетит.
Если вы видите что представитель подрядчика скучает на встречах, постоянно их переносит и вообще всячески дает понять что у него есть дела посерьезнее — ищите другого.
Без интереса к проекту, вас спихнут на самого хренового менеджера и дадут самую слабую команду — с соответствующим результатом.
Если у вас самого нет интереса (это моя работа, меня заставили и т. д.) — лучше даже не начинать. Слишком много времени и нервов это все стоит и слишком дорого.
Вообщем заказная разработка это всегда диалог на равных а не элитная проституция, как бы некоторым не хотелось.
Отдельно про бодишопы
Есть такой вид бизнеса, вроде как вариант аутсорсинга, под названием аутстафф — когда берется тело и целиком продается заказчику.
Т.е ваш сотрудник месяцами и годами работает в команде заказчика и на территории заказчика.
А вы получаете за это деньги, как заправский сутенер за своих девочек.
Главный корольбл#дейаутстаффа сейчас это Люксофт, отправляющий своих мальчиков-айтишников в лапы жирных банкиров по всей просвященной Европе уже не один десяток лет.
А так — опция с аутстаффом присутствует у любого крупного интегратора и аутсорсера, поскольку она выгодна, проста, понятна и удобна для крупного заказчика со своей отлаженной инфраструктурой.
К сожалению к реальной разработке это все имеет очень опосредованное отношение, поскольку таким аутстаффом закрывают дыры в штате и наращиваются уже существующие команды на уже работающих проектах.
Получаются такие гастробайтеры от компьютеров — «подай-принеси».
Я считаю бодишопы одним из видов современной работорговли и таким не занимаюсь.
Поскольку ни развивать ни обучать таких рабов на продажу сотрудников смысла не имеет, их просто массово отлавливают по подворотням, нанимают и выставляют на проект.
Как и что там будет с телом дальше — всем участникам процесса глубоко похеру, лишь бы числился и платежи шли.
Так что закончим с этом темой и идем дальше.
Техническое задание (ТЗ)
До того как будет написана хоть одна строчка кода вашего будущего проекта, необходимо потратить существенный объем времени и сил на ээм.. «полную ерунду».
Именно так позиционируется работа по составлению ТЗ представителями современных «гибких и клиенториентированных» аутсорсеров.
Делают они это не просто так, а с целью навязать варианты оплаты, подразумевающие бесконечное течение проекта и уплывающие в голубую даль сроки:
почасовка, фиксированный месячный бюджет, выделенная команда — конечно же с оплатой за количество голов на проекте.
Как вы уже могли догадаться — любая проволочка с вашей стороны (не предоставили вовремя доступ, затянули какое-то согласование, ушли в отпуск) легко и просто превращается в новый счет на оплату.
Примерно как абонемент в бордель, без возможности его постоянного посещения.
Еще вам постараются сразу продать евнуха и личного конюха выделенного менеджера проекта и тестировщика, что очевидно утроит стоимость проекта на ровном месте.
Я сильно против таких практик и всегда настаиваю на составлении ТЗ
Видимо поэтому до сих пор не катаюсь на мейбахе (или что там сейчас в моде среди членовозов?)
Зато у меня куча завершенных проектов, многие из которых работают до сих пор и если хотите чтобы ваш проект тоже когда-нибудь завершился, а не растекся лужей по временной шкале — читайте дальше.
Моя любовь к ТЗ имеет практический смысл:
У технического задания (как документа) есть свой жизненный цикл
Это не «write-once» отрывной талончик на вход, которым после начала разработки можно подтереться — как вам расскажут мои коллеги по цеху.
По завершению разработки вашего проекта, части из ТЗ пойдут на сопроводительную документацию — на руководства для пользователя, администратора и разработчика. Что-то будет добавлено в wiki проекта в качестве описания.
Любой серьезный рефакторинг, обучение новых разработчиков — все это требует информации по проекту, которая изначально была изложена как раз в ТЗ.
Вы не представляете сколько существует на свете софта делающего непонятную х#ету.
И когда из компании увольняются последние сотрудники, владеющие «тайными знаниями» о таком проекте — натурально приходится восстанавливать смысл его существования поиском по исходникам.
С соответсвующими рисками и результатом.
Вообщем всегда составляйте ТЗ до начала разработки, всегда.
Если сами не справляетесь — наймите специалистов, которые за смешные деньги (по сравнению со стоимостью разработки) вам его правильно составят.
Оценка проекта
Если вы сами не являетесь опытным ИТ-менеджером, собаку съевшим на оценке работ и четко понимающим ценообразование в ИТ — стоит заказать предварительную оценку проекта на стороне, прежде чем идти к аутсорсеру на подписание контракта.
Это нормальная практика, которая приветствуется нормальными компаниями, поскольку снимает с них часть рисков.
Немного расскажу как это происходит, поскольку тоже оказываю такую услугу. Существует методика оценки объема работ «в лоб», родом из 70х:
Предполагается что одну форму может реализовать один разработчик за один рабочий день.
Да это несколько наивно и сильно абстрактно, но в качестве предварительной оценки для типичного корпоративного софта — работает до сих пор.
Если у вас например мобильное приложение, в котором 20 экранных форм и все (ну опросник у вас или онлайн-тест) — его можно разработать примерно за один рабочий месяц одним разработчиком.
Конечно в реальности какие-то формы будут делаться быстрее, какие-то дольше, но в озвученные бюджет и сроки вы уложитесь.
Вообщем думаю идея понятна, так что едем дальше.
Допустим, в вашем проекте нужна интеграция с какими-то внешними сервисами — этот факт обязательно будет влиять на бюджет и сроки, временами драматически.
Обычно оценка каждой интеграции идет отдельно, исходя из смысла задачи и количества используемых функций и сложности передаваемых объектов.
Отдельным пунктом идет авторизация — облачная, через социальные сети, корпоративная и так далее. Тут обычно просто ставят фиксированную сумму, исходя из предыдущего опыта, конкретно на эту задачу, не углубляясь.
Вообщем мы постепенно приходим к следующему важному этапу — проектированию архитектуры.
Архитектура и проектирование
Скажу сразу, хоть я сам и являюсь архитектором, с подтвержденной практикой и опытом работы заграницей — не считаю начальное проектирование и составление «архитектурной концепции» обязательным решением для всех.
Во-первых, в компаниях, занимающихся заказной разработкой обычно есть свои люди, прекрасно разбирающиеся в том как проектировать и писать софт. И «внешние советчики» им не нужны, это считается «утратой компетенций».
Необходимость работы по чужому архитектурному плану скорее всего вызовет негатив — подготовленную концепцию глянет кто-то из «старослужащих» аутсорсера и выразит недовольство потоком технических терминов, из которых вы мало что поймете.
Вообщем аутсорсер может поднять цену или вообще отказаться от работы из-за такого, имейте ввиду.
Во-вторых это достаточно дорого, тратить $5-10к на документ про архитектуру имеет смысл только если вы на саму разработку готовы потратить в десять раз больше.
Если проект маленький (а таких большинство) — лучше сфокусироваться на описании бизнесовых высокоуровневых задач и составлении ТЗ.
Тем не менее, опишу случаи когда без проектирования архитектуры не обойтись.
Госзаказ
Тут даже нечего обсуждать — требования к проектируемой системе и ее сопроводительной документации описываются сразу в тендерных документах.
Поэтому если вы каким-то образом подвязались разработать софт для государства российского — готовьтесь миниум 30% времени и бюджета заложить на написание всей сопроводительной документации, по архитектуре в том числе.
Проект для большой компании
Если так получилось что вам надо разработать софт для «условного Газпрома или Сбера», пусть даже не очень большой и сложный — готовьтесь к соблюдению их внутренних регламентов.
Внутренее устройство вашей системы, авторизация, механизм работы с внешними сервисами и их список, журналирование, аудит, работа с базами данных, работа с файлами, процесс развертывания и реагирования на ошибки - все это у большой компании прописано во внутренних регламентах.
Нарушение регламента даже в мелочах означает переделку проекта за ваш счет, временами технически сложную и длительную.
Вот в этих двух случаях вам абсолютно точно нужен архитектор и этап проектирования, поскольку риски от «попытки зайти на авось» тут превышают все разумные пределы.
Прототипирование
Прототипы бывают разные — от рисования примерного внешнего вида форм и расположения ключевых элементов до полноценного работающего MVP — готового приложения, с живыми пользователями и контентом.
У меня лично двойственное отношение к прототипированию:
С одной стороны — это важно и нужно, сильно помогает на начальном этапе, поскольку визуализирует ключевой функционал, дает возможность оценить и прикинуть как приложение будет выглядеть и работать.
С другой — очень сложно остановиться в процессе ваяния прототипа, не потратив слишком много усилий на очень красивый макет, лишь чтобы потом разочароваться — когда дело дойдет до реальной разработки.
Любые инстументы для быстрого прототипирования позволяют очень быстро сваять нечто очень красивое и очень похожее на ваши ожидания — имейте это ввиду. Просто потому что скорость прототипирования и красота макета — их товар, то что они вам продают.
Реальная разработка будет заметно медленнее, а UI/UX будет отличаться в худшую сторону — про это надо помнить, чтобы не сваливать потом вину на криворуких программистов, не осиливших реализацию вашей мечты по мокапу.
Вообщем с горем пополам, вы выбрали себе подрядчика и заключили контракт.
Раньше еще был бы шаг предоплаты, но ее уже официально вроде как запретили, поэтому пропустим и перейдем к самой работе.
Работа наконец-то началась, прошла неделя или две и вам уже как-то надо контролировать процесс выполнения.
Контроль исполнения
Тут главное понимать что разработка ПО — процесс немного непредсказумый, нервный, еще и требующий фокусировки. Поэтому не стоит ожидать строго последовательного выполнения с предсказуемостью выхлопа фабрики.
Ну и абсолютно точно не надо лишний раз отвлекать разработчиков.
Проверить статус разработки раз в неделю-две — нормально, устраивать ежедневные часовые утренние митинги — нет.
Если вы торгуете акциями или продаете через холодные звонки — в этом случае наверное имеет смысл устраивать утреннюю оргию перекличку, требовать «всем быть ровно в десять на групповом звонке» и все в таком духе.
Но в разработке софта весь этот скотский цирк не работает — вы просто за#бете людей и вся работа над вашим проектом встанет намертво.
Я лично всегда поступал следующим образом:
Раз в неделю, обычно в пятницу вечером составлялось «письмо счастья», с текущим состоянием дел и скриншотами реализованного функционала.
В понедельник заказчик открывал почту и радовался, многим это помогло пережить тяжесть понедельника в крупной компании.
Временами записывались и отправлялись ролики с демонстрацией работы, если функционал был каким-то визуально сложным и многослойным.
Этих двух методов вполне хватало для формирования ощущения контроля на проектом, что все на проекте идет хорошо.
Примерно раз в месяц можно попросить устроить вам показ в живую - на тестовом стенде.
если происходит разработка с нуля — что-то показать можно будет только через две-три недели разработки, не раньше.
Это нормально, поскольку за этот период будет создаваться техническая основа вашего приложения, базовые объекты, сущности и формы.
Чтобы вас как заказчика не пугать и не допускать ощущения просирания всех полимеров на начальных этапах — сроки на создание первой версии обсуждаются заранее и отдельно.
Ну и наконец последняя, но тоже весьма важная часть нашего сегодняшнего балета.
Передача результатов работы
«Как забрать результат» — еще та проблема если результат цифровой, поэтому дам несколько советов.
поддерживайте бл#ть пожалуйста нормальные отношения с контрагентами
Самый простой и надежный способ быстро поправить любую ситуацию с вашим проектом это сохранять хорошие отношения с аутсорсером по завершению этого самого проекта.
И речь тут не про совместные пьянки и походы по горам — хотя-бы нах#й не посылайте, уже хорошо будет.
Ну и думаю очевидно что никаких задолженностей по оплате с вашей стороны быть не должно:
возможно вы не в курсе, но 70% затрат в любом бизнесе связанном с ИТ это затраты на персонал а не на золотой мерседес директора
Что случится если вы будете тянуть с оплатой? — сотрудники аутсорсера не получат зарплату и либо свалят сами либо их сократят.
И это будут именно те сотрудники, которые работали над вашим проектом — сократят людей в первую очередь с убыточного проекта.
Вообщем своими задержками по оплате и задолженностями вы неслабо так выстрелите себе же в ноги.
Теперь про сам процесс передачи.
Если у вас с взаимоотношениями все осталось хорошо — после любого проекта заказной разработки будет период поддержки, либо бесплатной -месяц-два, либо за какой-то мелкий прайс — сколько вамбудет надо.
В этот период будут исправляться найденные недочеты, обновляться библиотеки и обеспечиваться совместимость.
Также будет постепенно накапливаться пул задач на новый этап доработок, который в итоге превратится в новый контракт.
Вообщем если у вас хорошие отношения с подрядчиком — можете не заморачиваться особо с деталями процесса передачи.
Поскольку разработка и поддержка это отношения на годы и годы вперед — никто в здравом уме резать курицу, срущую золотом не будет.
И все ваши проблемы как-нибудь но решат.
Плохой конец
Вот теперь про другой вариант, на разгребание последствий которого меня почему-то регулярно привлекают.
По некоей неведомой причине (объективной или нет — уже не важно) подрядчик вас не устроил и вы (ну ваша компания) не нашли ничего лучше чем:
а) кинуть его на оплату, угрожая судом;
б) выразить свое «фи» личным посылом нахер их представителя: РП, ПМ, в особых случаях — лично гендира.
То есть никакого желания общаться с той стороны нет вообще.
При этом проект ваш подвис в воздухе на той стадии где вы (ваша компания) начали буйствовать:
это может быть и стадия прототипа и тестовая версия уже на вашем стенде, но без исходников и релиз в продакшне, но без переданных обновлений — все что угодно.
Вам придется умерить пыл и все же идти договариваться, в первую очередь решив вопрос с оплатой.
обычно увидев новое лицо, получив оплату и формальные извинения — подрядчик идет навстречу и вопрос решается полюбовно.
Все же деловые люди, бизнесом заняты а не ерундой.
Поверьте моему опыту: умерить пыл и договориться это лучший вариант из возможных
Хотя бывает что вам поступает указание свыше «слать всех нах» и доделывать проект своими силами или с кем-то другим.
Да, я тоже был когда-то молод и думал что могу все и сам, что мне море по колено — всю эту дурь выветрил полученный опыт, которого у вас скорее всего нет.
Поэтому вкратце расскажу что потенциально вас может ожидать при таком варианте.
Неполная передача дел
Наверное вы слышали такой термин «итальянская забастовка»?
Когда разозленный народ начинает до самой мелочи исполнять абсолютно все существующие правила и регламенты, которых внезапно оказывается миллион.
Обязательно найдутся и противоречащие друг другу и неточные и допускающие вольные трактования. И вот уже жизнь превращается в ад проверок и согласований, а работа встает колом под разными формальными, но абсолютно законными предлогами.
Вот и с вашим проектом могут сделать подобное.
Самый простой вариант — реализовать какой-то важный, но незаметный сразу кусочек проекта в виде отдельной библиотеки и «забыть» про нее упомянуть и передать исходник.
— Передача исходного кода была?
Есть еще более эпичная вариация:
чуть доработанная аутсорсером известная и популярная библиотека, идущая в довесок к вашему проекту.
Определить такое невероятно сложно, поскольку название будет от оригинальной библиотеки а версия чуть-чуть отличаться.
С учетом того что практически все ИТ-компании сейчас используют персональные репозитории вроде Nexus, с проксированием и библиотеками для всех популярных языков (Java, .NET, Node.js) - вы это гарантированно пропустите, даже если будете про такое знать.
На контрольной сборке все пройдет отлично — все будет собираться даже с отключенным и удаленным локальным кешем.
А затем аутсорсер отключит свой Nexus для вашей компании и все внезапно на#бнется.
Начинаете понимать, почему я так советовал умерить пыл и договариваться?
Если нет то вот вам еще пример.
Бомба обновлений
Есть на свете такая вещь как «deprecation» — устаревание. В мире софта устареть могут даже отдельные методы и функции в библиотеке или фреймворке, на такие методы ставятся метки "deprecated":
Дальше через какое-то время, обычно не сильно большое — полгода, год, два, такие функции и методы будут удалены из новых версий библиотеки, а ваш проект, который их использовал — просто сломается на очередной сборке.
Самый простой способ вам это обеспечить — использовать сырые (альфа-бета-release candidate) версии библиотек, вместо релизных.
Не обязательно весь проект переводить только на такие библиотеки — это будет заметно, достаточно двух-трех ключевых.
Спросите а как же бинарные сборки?
Дело в том что на зависимость с сырой библиотекой обычно ставят нечеткую версию и автоматическое обновление до текущей.
Это например знаменитое: ~ в номере версии подключенного пакета npm (в package.json)
И все, оно само скачается и сломается при сборке.
Где-то через полгода после полной передачи проекта в ваши руки.
Итоговые мысли
Самое важное что я хотел донести в этой статье: необходимо договариваться и идти на компромиссы.
Разработка это сложно и тяжело, точно сложнее чем пошить для вас хороший костюм или сделать лакированные туфли.
Как «принимающая сторона» — я кровно заинтересован в адекватных заказчиках, длительных деловых отношениях и предсказуемых проектах без авралов и сюрпризов.
Очень надеюсь что потенциальные заказчики прочитают эту статью, сделают правильные выводы и хоть одним говнопроектом на свете станет меньше.