«Переделываем за строителями — быстро, дорого, нормально»

Это снова мы — компания Qtim, которая успела описать обещанный кейс и даже наконец-то сделать себе новый нормальный сайт.

Иногда чувствуем себя той самой тетенькой. Мы это к чему: в первой статье обещали рассказать, как выглядит на практике все то, о чем в ней написано. И говорили, что сделаем это на примере «Онлайн-школы №1». Обещали – рассказываем.

Постараемся не выдать классический кейс «все было плохо, но мы не делали плохо, мы делали хорошо, ну вот хорошо и получилось». Вот о чем расскажем вместо этого:

• Что помогло нам уложиться в сроки, в которые сами не до конца верили
• Где лежали грабли, которые мы нашли в этом проекте
  

• Как выглядит внутряк разработки и взаимодействия с клиентом на большом проекте, как он влияет на работу

• Какие выводы о работе с клиентами мы сделали за время этого проекта

Начнем как раз с одного из выводов. Здесь надо сделать отступление, важное для понимания всего, что написано ниже. А то будете читать и думать: «Врете вы, ребята, не бывает в природе таких покладистых клиентов».

«Покладистость» ни при чем. Главное, что сыграло роль, – мы не делали разработку с нуля, а переделывали. Это имеет свои последствия, главное из которых: несделанная (или плохо сделанная) работа имеет свойство накапливаться в организме и подогревать дедлайны.

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

У такого подхода есть плюсы, есть минусы:

+ Клиент уже в чем-то разбирается, даже если изначально он ничего не понимал в разработке.

+ Когда дедлайны жмут, из этого тоже можно извлечь пользу. Потратив определенное количество времени, выделенного на проект, клиент не склонен долго думать над каждым решением.

– Но и верить нам клиент не склонен, даже несмотря на то, что пришел по рекомендации. Его легко понять: один раз его ожидания уже не оправдались.

– Времени объективно меньше, чем нужно. Приходится не просто делать работу, а придумывать, как ее сделать вовремя.

Так же, как и большинство других. Узнав за несколько месяцев и n денег, что с предыдущим подрядчиком работа не складывается. Это как раз тот случай, когда применимо написанное выше.

Потребность: написать платформу для онлайн-обучения, на которой могут учиться одновременно несколько тысяч учеников.

Две проблемы: горящие сроки и недоверие. С какой начать, как считаете?

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

И не получится начать с того, что «мы классные ребята, погнали делать ваш проект». Клиенту надо посмотреть наш уровень.

С мая 2021-го. Начали мы не с платформы – основного продукта, по которому горели сроки.

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

Мы посмотрели на код и пригладили вставшие дыбом волосы, чтобы сидеть не мешали.

Отступление для понимания. Вот 300 часов доработки – это много, как считаете? Да, это много. За 300 часов можно с нуля поднять мобильное приложение, и не самое простое.

Так вот: мы смогли выторговать те самые 300 часов, чтобы с энциклопедией можно было хоть как-то работать. Хотя бы – чтобы не ломался процесс забора данных, работали сортировки и не терялся контент. Отдельный респект любителям React за тесты, сделанные целиком на фронте, – этим до сих пор джунов пугаем.

Так что исходники фронта пришлось взять старые, но его делали уже с нуля, натягивая на более-менее рабочий бэк, надежно подпертый костылями. Костыли, к слову, мы отлаживаем сейчас, на +/- спокойном этапе поддержки. Энциклопедия и по сей день в продакшене, ее можно посмотреть на сайте школы.

С октября по середину ноября мы вели диалоги. Параллельно готовили бэк, фиксили баги, но с пользовательской точки зрения ничего не делали – только разговаривали. С клиентом были созвоны по 3–4 часа 3 раза в неделю. Обсуждали функционал – он громадный. В нем несколько ролей, подроли и так далее. Для понимания ситуации на старте: так выглядели прототипы, которые нам передали от предыдущей команды ↓

Долгие переговоры на старте – неизбежный этап, если мы хотели закончить к апрелю. Вопросов было много.

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

Со стороны подхода к планированию работ

Согласовали с клиентом работы → пообщались на дейлике с командой, как лучше сделать → побежали делать. Безо всяких модных принципов проджект-менеджеров: «если задачи нет в таск-трекере, задача не делается независимо от ее важности».

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

Со стороны взаимодействия с клиентом

Взаимопонимание. Пафосно, но по факту. Взаимопонимание родилось после того, как мы сдали энциклопедию и 1,5 месяца перетирали с клиентом детали основного проекта. Ближе к концу проекта общение велось примерно в таком тоне (на белом фоне – клиент):

Со стороны согласования

Крайне редко – разве что на первом спринте в проекте – мы делали только бэк без фронта. А значит, после каждого спринта клиент мог что-то пощупать – функционал или фичу.

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

В конце спринта продакт-менеджер Женя тестировала и говорила – а давайте вот так, будет удобно. Мы смотрели, укладываемся ли в сроки. Если да – делали. Если нет – говорили: «Жень, давай в условный MVP-2, не сейчас».

Со стороны работы с командой

Да, честно говоря, просто пахали как не в себя. Вообще нет секретного ингредиента. В пиковые моменты над проектом работали одновременно 17 человек.

С юридической стороны

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

С технической стороны

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

Мы начали прорабатывать дизайн роли администратора. Это роль, которой доступно вообще все: добавление, редактирование, удаление и чтение всего. Отрисовали все, что ей доступно, и смогли понять, какие функции в целом планируются на платформе. От этого отталкивались – расписывали user-story. И она получилась такой, что волосы вновь зашевелились.

Поясним. Клиент не знал на входе, что он хочет видеть по ролям. Если бы мы зашили монолитом какие-то роли и их характеристики – 100% сорвали бы сроки. Потому что неизбежна ситуация, когда в середине большого проекта клиент говорит: «Мы тут подумали…» А мы такие – нууууу, дайте еще пару месяцев, сделаем.

Вот именно поэтому мы долбили себе мозг: давай что-то придумывать, иначе потом роли мы не поменяем. А менять придется, потому что клиент пока сам толком не знает, что ему нужно. У него есть, конечно, видение, но конечной точки, как будет выглядеть система, нет. Да о какой конечной точке речь – на старте не было даже понимания, какими правами какой пользователь должен обладать.

Для понимания масштаба – скрин из Miro, сделанный примерно в середине процесса. По факту фич примерно в 2 раза больше. Зеленое и голубое – роли, синее – нужный для каждой роли функционал.

В итоге мы пришли к тому, что сделали виджетную систему гибких ролей. Она позволяет за 2–3 минуты создать роль с определенным кругом прав. Виджет – это блок в приложении – как в любой CRM-системе типа «AMO» или «Битрикс 24». Этот блок можно либо читать, либо редактировать, либо запретить доступ к нему. Мы сделали несколько десятков таких виджетов, и каждая роль имеет один из трех вариантов доступа к каждому.

Грубо говоря, подход таков: мы не писали роли. Вместо этого мы сделали конструктор, который позволяет быстро их создавать и редактировать. Создавая в нем роль, мы добавляем галочки к каждому виджету, как это сделано во многих CRM-системах. Назвали новую роль, натыкали галочки – все, она есть на платформе, можно туда добавлять новых пользователей.

Был момент, когда мы на себя уже нимб примеряли. Мол, одни мы хорошие. Все клиентам делают фигню, они страдают, приходят к нам, а мы их спасаем за большие деньги.

А потом подумали, потрезвее посмотрели на ситуацию и нимб отложили в сторону. Особенно после того, как Антон за день до релиза уронил календарь и сидел его поднимал на дне рождения своей бабушки.

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

Одна из банальных причин:

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

Есть компании, которые уже клонятся к закату. Уходят компетентные сотрудники и руководители, стопорятся отлаженные процессы, в команде витает атмосфера «а уже пофиг». Увы, наличие таких компаний на рынке неизбежно. У них есть жизненный цикл – ни один бизнес не вечен.

Есть компании, которые находятся «в расцвете сил». Мы не знаем соотношение, не исследовали рынок. Но вряд ли ошибемся, если оставим по 25% на молодые и умирающие бизнесы. То есть вероятность попасть к хорошему исполнителю уже всего 50%.

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

• Попали на добросовестного продавана, который заводит только такой проект, который компания способна вытащить? Или нет?
• Пришли в момент одного из внутренних кризисов роста или в период, когда все хорошо работает?
  
• Попали на грамотного проджект-менеджера или на унылое тело, которое думает только о смерти и иногда – об отпуске?
  
• И так далее.

Так что это не мы такие классные. Классных разработчиков много. Но хватает и тех, с кем клиентам не везет. Причем так работает не только в разработке – вообще в любой сфере.

По итогу прочтения могло сложиться примерно такое ощущение: да это же трындец и хаос, а не разработка. Знаете, что мы на это скажем?

До релиза мы работали 5 месяцев и до последнего боялись не успеть. Но успели – и релизнули платформу в том состоянии, что туда можно завести не один тестовый класс, а тысячи человек – и она будет работать. Это ни разу не идеал, дальше тоже были нужны фичи. В основном уже не для учеников, а для персонала и для маркетинговых вещей

Зато можем твердо назвать отклонение от идеала: 2,5 балла по 10-балльной шкале. После релиза мы выкатили опрос пользователей по 27 параметрам. Итоговая оценка – 7,5.

И да – это и правда трындец и хаос. Важный нюанс: управляемый хаос и локальные трындецы, которые появляются и исправляются по ходу спринтов.

Мы не видели примеров, когда в разработке больших проектов все идет ровно, рядком и по плану. Вопрос только в том, получается управлять происходящим или тебя наматывает на эту мясорубку и потихоньку прокручивает в фарш. Так что, на наш взгляд, платформа «Онлайн-школы №1» – стандартный real-time проект. Если только слово «стандартный» вообще имеет право на жизнь в таком контексте.