Мир ИТ-услуг весьма странен.
С одной стороны, вроде все заказчики всё знают: о гарантированно провальных проектах, засилье говнокодеров, непрофессионализме менеджеров и тимлидов, низком качестве продуктов. Невозможно этого не знать, рынок давно сформировался, устоялся и не собирается качественно меняться. По крайней мере, в лучшую сторону.
С другой стороны, продолжают покупать. Это понятно – выбора-то особо нет. Будь на рынке реально крутые, качественно лучшие игроки – законы конкуренции доделали бы остальное.
Непонятно другое – все делают вид, будто никто ничего не знает. Заказчики на полном серьёзе обсуждают предстоящий, непременно успешный проект, а говнокодеров называют «специалистами». ИТ-компании – подыгрывают. Хорошо ещё, большинство встреч проходит онлайн – не приходится продумывать логистику офиса, чтобы просранные клиенты не столкнулись с невинными потенциальными.
Итог всегда один, просто достигается за разное время, кому как повезёт. Кому-то выпадет счастливый билет, и попадётся действительно классный программист или целая команда. Но это лишь продлит агонию – никакой программист, и никакая команда не будет с заказчиком всегда. Штурмовые бригады идут дальше, а на замену приходят охранные войска – ополченцы, грубо говоря. И разочарование заказчика ИТ-миром в целом произойдёт обязательно.
А бывает ли по-другому? Речь не про сказку об очередном мифическом деревенском программисте, который с пинка открыл дверь собственника и всё ему объяснил, нет. Бывает ли так, что не обманываются ожидания?
Конечно. Чтобы не обманывались ожидания, рычага есть два. Первый – соответствовать ожиданиям. Второй – корректировать ожидания. Я сегодня про второй.
Есть у нас команда, которая…. Как бы это выразиться. Странная короче. Они говорят заказчику всё, как есть. И предлагают выбор.
Кто главный?
Первое, что предлагают выбрать, – кто главный в автоматизации. Главный, вопреки расхожему мнению, не тот, кто платит.
Выбор простой. Или заказчик говорит, что делать, а команда исполняет. Или команда говорит, что будет делать она и заказчик.
В автоматизации, в большинстве случаев, всё действо начинается с проблем заказчика. Чтобы решить проблемы, надо предпринять какие-то действия – внедрить систему, заменить одну на другую, сделать или переделать сайт, запилить интеграцию, уволить главбуха и т.д. И, к сожалению, почти всегда есть выбор – что конкретно сделать и как именно.
Осуществляет выбор тот, кто назначен главным. Кого назначить – пусть решает заказчик. В качестве бонуса к выбору идёт ответственность. Тут всё тоже очень просто.
Если заказчик сам себя назначает главным, то он отвечает за адекватность выбранных решений исходной проблеме. Если деньги потрачены, автоматизация выполнена, а проблема не решена или усугубилась – ну, извините. Хотели покомандовать – мы были рады поисполнять. Команда в данном случае отвечает лишь за качество решения, т.е. его соответствие требованиям.
Если заказчик выбирает главным команду, то должен слушаться. Потому что, как вы знаете, в подавляющем большинстве случаев дело не в автоматизации. Ну и вообще, главного надо слушаться – его за этим и выбирают.
Технология выполнения проекта
Тут всё просто. Есть классический водопад/каскад, есть эджайл. Понятно, что дурная голова и эджайл по плану-графику делать будет, но тут дураков, вроде, нет.
Итак, заказчику дают выбор: делаем проект как ты хочешь, или так, чтобы было успешно. Явно немного манипулируют, вкладывая оценочные суждения, но что ж теперь – тоже люди.
Заказчик на входе всегда хочет так, как умеет, а точнее – как привык. Ему нужен бюджет, сроки, план-график. Ему нужна иллюзия контроля и управляемости этого спектакля.
Команда кратенько рассказывает заказчику, что будет при таком подходе. Первую треть времени всё будет идти прекрасно. Программисты и аналитики будут работать, выдавая горы «результата» - бумаг для подписания, прототипов, тестовых баз и функциональности. Все начальные этапы проекта почти всегда проверяются и принимаются в некоей виртуальной тестовой среде, ограниченным количеством людей, без участия реальных пользователей, их данных и буйной фантазии.
На второй трети проекта будет происходить тестовая эксплуатация и начнутся первые проблемы. Окажется, что функциональные требования никуда не годятся, и делать надо, в лучшем случае, по-другому. В худшем – совсем по-другому. Запустится цепочка уступок – никто не хочет возвращаться к исходной стадии и переделывать, ведь акты подписаны – заказчик ответственность на себя взял. Ставится маркер «ладно, пусть так будет», но следующие шаги основаны на предыдущих, и если те были «ладно, пусть так будет», то и дальше придётся двигаться в соответствии с планом. И так до взрыва.
Взрыв происходит где-то на 2/3 проекта. Полуработающая система уже не нравится никому и не может развиваться в прежнем ключе. Очень часто в этот момент выгоняют руководителя проекта со стороны заказчика. Планирование и вся красота колбасок Ганта выключаются, начинается кровавый эджайл, с экстремальным программированием и частыми-частыми релизами.
Да, и начинается жуткий срач насчёт денег. Планировали одно, выходит другое. Заказчик хочет заплатить прежнюю сумму. Исполнитель не согласен реализовывать возросшие требования за те же деньги, и хочет доплаты. Ну и так далее, сами знаете. Приходят к некоему компромиссу, чтобы побыстрее друг от друга отделаться.
Всё это команда красочно, с примерами, описывает заказчику. И предлагает альтернативу.
В целом, альтернатива – эджайл, хотя в каждом конкретном случае, в зависимости от проекта, детали его различны. Но принцип один: определяется ближайшая цель, релиз (не технический, а, скажем так, проектный), все упираются и делают этот релиз. После берётся пауза, определяется следующая цель, все упираются и делают. И т.д.
При эджайле даже близко не понятно, сколько денег и времени уйдёт. Полная неопределённость. При каскаде ещё хуже, там вместо неопределённости – иллюзия.
И пусть заказчик выбирает. А потом не жалуется.
Оценка работ
Любой приличный программист знает, чего не знает. А не знает он, сколько времени займёт работа. Исключение – только понятные, много раз выполненные ранее задачи. Ну, любой программист знает, что таких почти не бывает.
Любой заказчик на входе хочет знать, сколько времени и, соответственно, денег потребуется на выполнение работы. Все соседние отделы воспринимают это требование клиента, как незыблемое, и бегут делать сложные расчёты с учётом рисков и т.д.
Команда, о которой я рассказываю, даёт выбор. Лучшим называют вариант, когда программист просто решает задачу, а итоговая стоимость складывается из его трудозатрат. Второй вариант – как у всех, предварительная оценка.
За годы работы у ребят накопилась статистика, которую они озвучивают клиенту для облегчения выбора. Работа с предварительной оценкой стоит в 2-4 раза дороже. Как ни странно, даже зная этот коэффициент, заказчик зачастую выбирает предвариловку. Сила иллюзий.
Выбор спеца
Программист программисту рознь. Один будет неделю сидеть, второй сделает за час. Просто потому, что уже делал такое.
Конечно, изначально заказчику всей этой кухни знать не хочется. Хотя, вот лично мне это кажется странным. В личной жизни каждый человек, в т.ч. – представители заказчика, делают подобный выбор постоянно.
Например, врачи в платной и условно бесплатной медицине. Хочешь срочно какого-нибудь терапевта – получаешь какого-нибудь терапевта, с ценой приёма в 1 тысячу рублей. Хочешь не абы какого, а к.м.н. – изволь 1.8 т.р., да ещё и по предварительной записи. Ну а если тебе понадобился наш городской светило, изволь 3-5 т.р. за приём, и в очереди отстоять месяца три. И ведь никто не возмущается, потому что всегда есть выбор.
Может, я кому секрет раскрою, но один программист может отличаться от другого так же, как студент 1-го даже не курса, а дня обучения в медицинской академии отличается от Леонида Рошаля. Блин, ну ясен перец, что их работа стоит совершенно разных денег. И результат, соответственно, тоже весьма неодинаков.
Команда даёт выбор из нескольких вариантов. Первый – базовая ставка за час, работает миддл. Вторая, в 2-4 раза выше – работает эксперт (15+ лет опыта). Третья – нечто среднее, работает миддл, но под присмотром эксперта, с проверкой кода, архитектуры и общего направления решения. А для простой работы сдают по фиксированной стоимости за день джунов, для которых главная валюта – интересные, развивающие задачи. Кстати, этот подход тоже отличает команду – соседи сдают джунов по цене миддлов. А экспертов не сдают – их там нет.
Выбор качества
Ну и напоследок – выбор качества решения. Эту вилку приходится предлагать, по сути, для каждой задачи.
Первый, базовый, лоховской уровень – «лишь бы работало». Любой программист знает, что «программа работает» - это не цель, а повод хотя бы обратить на неё внимание.
Средний уровень – сделано качественно, но хрен пойми что. Так бывает в случаях, когда заказчик сам ставит задачи.
Высокий уровень – задача решена качественно, проблема устранена. Это вариант, когда решение под проблему подбирала команда, а не заказчик.
Ну и высший уровень, который случается редко – проблема-то совсем в другом.
Что выбирают заказчики?
Тут никаких сенсаций не будет, я ж говорил – не сказка это.
Кто главный? Конечно, заказчик. Ещё ни один не выбрал главным подрядчика. Но есть одно большое «НО» – ни один ещё не пискнул на тему «а проблема-то не решена».
С технологиями выполнения проектов 50/50. Точнее, начинают все с каскада, делают на нём первый проект, а на последней стадии команда тычет заказчика носом в «мы же говорили». Дальнейшие проекты выполняют по эджайлу.
С оценкой работ аналогично. Поначалу говорят «это всё, конечно, очень интересно, но скажите, сколько это будет стоить». Тут команда приёмчик придумала. Называют стоимость, делают работу, а потом говорят – аналогичную задачу решили другому клиенту за такую-то сумму. «Такая-то сумма» оказывается в 2-4 раза ниже. После нескольких итераций клиент перестаёт спрашивать предварительную оценку. Тут, думаю, дело в доверии, которое в любом случае надо заработать.
С выбором спеца всё предельно просто. Никто не хочет лютого говнокода, и никто не хочет переплачивать. Все выбирают золотую середину – работу миддла под присмотром эксперта.
А качество решения какое выбирают? Не важно. Важно, что научились выбирать правильно. Для одноразовых проблем – дешёвый быстрый говнокод. Для системных неважных проблем – средний. Для больно бьющих – высокий. Ну и раз такое дело, допустили программистов до решения и фундаментальных проблем бизнеса.
Что в итоге
Если честно, нет единого мнения. Хочется, конечно, этих провокаторов выставить супергероями автоматизации, но не так всё гладко.
Первое – у них самый высокий процент отвала клиентов. Отваливаются на стадии переговоров – кому охота терпеть шибко умные рассуждения программистов. От заказчиков приходят не роботы, а люди. Они хотят, чтобы их обслуживали, а то и облизывали – все ж «Красотку» смотрели.
Второе – они задолбали всех окружающих. У вас могло сложиться впечатление, что команда просто даёт выбор и потом работает так, как решил заказчик. Увы, фигушки. Если заказчик сделал «неправильный выбор», велик шанс, что команда его отвергнет. Просто потому, что у них определённый лимит на «плохих» заказчиков, и он весь выбран.
Третье – ставка часа и деньги. Ну, тут нечего сказать. Ставка часа у них в среднем выше, денег они зарабатывают больше. Козлы.
Четвертое – лояльность клиентов. Увы и ах, но клиенты у них не уходят. Бывает, что команда сама пытается избавиться от клиента, подсовывая ему другую команду на определённые задачи – заказчик чувствует слишком сильный контраст и бунтует.
Пятое – душевное состояние сотрудников. Оно в команде лучше, чем у конкурентов. Потому что никому не надо никого из себя строить. Если заказчику сказали «с тобой будет работать джун, он ни хрена не умеет, главное убедись, что он запись звонка включил – потом ребята ему помогут», то ни заказчик, ни джун не парятся.
Хотелось бы, конечно, закончить чем-нибудь эдаким – как команда захватывает рынок, все заказчики толпой бегут к ним, и вообще их покупает гугл. Но нет, увы.
Ребята просто нашли маленькую, интересную нишу и заняли её. Они просто называют вещи своими именами, как рекомендовал Конфуций. В чём-то они стали лучше окружающих, в чём-то уступили. Но: заказчики довольны, команде прикольно.
