Как гибкая разработка и планируемый бюджет помогают нам поддерживать и развивать сайты клиентов. Опыт IT-компании.

Главные вкладки

Аватар пользователя Drupal Coder Drupal Coder 23 сентября 2022 в 14:21

Чтобы занимать лидирующие позиции в своей отрасли, бизнесу нужно постоянно развиваться. Уже недостаточно просто сделать сайт и ждать клиентов.

 

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

 

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

 

Мы в Initlab убеждены, что сайт — это процесс, а не готовое решение. Постоянное планирование, баланс между решением текущих задач и введением новых функций: сделали, проанализировали, наметили улучшения — эта песня без конца, начинай сначала.

 

Наша задача не просто поправлять мелкие недостатки — мы заинтересованы в долгосрочном развитии сайта клиента. Ради этого мы столько лет в IT.

 

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

 

Коротко о себе и наших клиентах

Мы — Initlab. Крутая команда специалистов с опытом от двадцати лет в web-разработке и от 15 лет в Drupal. Нас зовут, когда сделано простое и осталось сложное. Когда все отказались или всё сломали. Когда масштабные проекты, которые заказчик хочет развивать.

 

В 2020 году наш клиент PNEVMOTEH получил премию «E-COMMERCE» как лучший интернет-магазин среди малого бизнеса.  В 2022 компания сменила весовую категорию и стала вторым лучшим интернет-магазином Беларуси, уступив место только МТС. Есть над чем работать и к чему стремиться.

Другой наш клиент — завод «Альверо», из-за специфики бизнеса делал упор на офлайн-продажи. Качество премиум-дверей клиенту лучше оценить лично: потрогать материал, изучить фурнитуру, послушать продавца. С приходом пандемии потребовалось дополнить модель продаж системой онлайн-заказов. При разработке сайтов мы закладываем архитектурные решения, которые предполагают развитие и расширение. Поэтому задача от клиента поступила на подготовленную почву: мы внедрили онлайн-заказ на сайт суммарно за 30 часов. Без грамотной архитектуры на это ушло бы от месяца и больше.

RASTL.RU — интернет-магазин, который уже более 10 лет на рынке текстильных товаров. Их сайт — один из основных инструментов продаж, над которым мы также постоянно работаем. В 2021 году государство потребовало маркировать текстиль и одежду по системе «Честный ЗНАК», что повлекло за собой ряд проблем с онлайн-торговлей. Благодаря тому, что наш разработчик до этого написал и внедрил на RASTL.RU специальный модуль для отправки чеков по 54-ФЗ, мы смогли без труда доработать его архитектуру так, чтобы нужная информация уходила теперь и в систему ЧЗ. Об этом мы писали здесь.

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

Как строится гибкая разработка

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

 

В классической поддержке сайта сценарий такой:

 

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

 

В случае с гибкой разработкой, после обращения клиента, происходит следующее:

 

1. Рассчитываем примерное время, которое уйдёт на всё запланированное. Ключевое слово — примерное. Мы не даём точную оценку на доработку сайта в случаях: 1) если сайт делали не мы и не знаем, как он написан; 2) если нам предстоит делать нечто новое и мы пока не понимаем, что и сколько займёт. Мы даём ориентировочную оценку по запросу клиента, исходя из нашего опыта.

2. Согласовываем оптимальный бюджет в месяц. В классической ситуации клиент получает счёт в конце месяца/квартала по факту выполненных работ. Для гибкой разработки нужно, чтобы клиент определил сумму, которую готов вкладывать в поддержку и развитие сайта в месяц, а мы рассчитали, хватит ли её для занятости нужного состава команды и планируемых задач. Для чего это служит, расскажем ниже. Когда бюджет согласован, мы подписываем договор.

3. Расставляем приоритеты по задачам. Что нужно сделать срочно, что пока терпит, а что делаем на оставшийся бюджет? Чаще всего распределяет задачи по важности клиент, особенно если проект большой и дел там невпроворот. Со своей стороны мы даём список задач, о которых клиент с его позиции может не задумываться: тестирование сайта, устранение технического долга и т.п.

4. Распределяем бюджет между всеми задачами, которые планируем. Самому важному пункту — отдельный раздел.

Распределяем бюджет

Все проекты разные и одного рецепта нет, поэтому в качестве примера мы опишем типовой вариант того, куда уходят средства. Итак,

 

1. Контроль состояния сайта с помощью ручных и автоматических тестов. Работает ли корзина? Какой результат даёт поиск по сайту? Не поехала ли вёрстка? Всё это нужно проверять после каждого изменения/обновления. На маленьких проектах хватает человеческих сил, на крупных уже нужна автоматизация.

На постоянное тестирование уходит примерно 20% бюджета.

2. Проблемы, баги, оперативные задачи — из разряда «всё бросить и бежать чинить корзину». На это мы выделяем примерно 30% бюджета.

 

3. Технический долг — устранение накопленных ошибок и недоделок. Прошлые разработчики не всегда оставляют сайт в идеальном состоянии. Мелкие недочёты могут замедлять сайт и усложнять разработку. На устранение технического долга уходит около 10% бюджета.

 

4. Обновление до актуальных версий ПО сайта. Например, апгрейд Drupal с 7 до 9 версии. На это закладываем около 10%

 

5. Новые бизнес-функции. Мы с заказчиком составляем road-map: каким будет сайт через год-два и какие функции он хочет там видеть. Для большого бизнеса это едва ли не самая необходимая часть работы, поэтому на неё уходит порядка 30% бюджета.

 

Если «дожать» смысл, то всё вышесказанное помогает нам держать на проекте баланс: решать срочные задачи, параллельно гармоничного развивать проект. Грубо говоря, тушить пожар и одновременно сажать новые деревья — это и есть гибкая разработка.

 

Процентовку из нашего «примера в вакууме» можно распределять как угодно в соответствии с текущими целями и задачами. Мы бережём до конца месяца 30% на срочные задачи, но ничего не случается? Выделенные на это часы можно потратить на обновление безопасности. Закрыли технический долг, который мешал нормальной работе быстрее, чем планировали? Оставшийся бюджет пустим на что-то другое.

Пока проект развивается, мы всё время анализируем, нужны ли ему новые бизнес-функции, работаем над ускорением сайта, обновляем все доступные модули Drupal. Если сайт развивается вширь — у него появляются языковые версии, то наша задача создавать его копии. На масштабных проектах нужно сделать так, чтобы изменения вносились в одном месте, а обновлялись на пяти сайтах.

 

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

Распределение задач

Для клиента всё это может звучать пугающе. Откуда ему знать, что мы разобрались с основными проблемами и начали улучшать проект по нашему плану. Как говорится, звучит красиво, но чем докажешь? Один из наших главных принципов — открытость. И его легко соблюдать с помощью сервиса постановки и контроля задач (трекера).

 

Мы даём клиенту доступ к трекеру и учим им пользоваться. Здесь можно следить за всеми процессами. Но в первую очередь вместе с заказчиком мы заводим нужные задачи в систему и расставляем их приоритеты. В любой момент можно добавить, изменить или уточнить то, что нужно.

Задачи распределяются между прикрепленными к проекту специалистами в порядке приоритета по их специализации (фронт, бек, администрирование и т.д.)

 

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

Страхи клиентов: отсутствие задач, пауза на проекте и затягивание сроков

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

 

— Давайте когда будут задачи, тогда и оплатим.

 


Суть планирования бюджета в резервировании времени разработчика. Если специалист не занят вашим проектом, скорее всего он занят другим и выдернуть его оттуда сложно — он своё время распределяет там, где есть план работ и понятный заработок. Как только на него упадут задачи с внепланового проекта, скорее всего он будет очень долго до него добираться, потому что график забит. Если заказчик готов ждать месяцами, то такой формат работы в принципе возможен. 

 

— А если задач не будет/их будет мало/у бизнеса будут трудности, а бюджет уже оплачен?

 

Здесь всё просто: если задач мало — мы перераспределяем время на то, что не связано с бизнесом напрямую: рефакторинг кода, настройка тестирования и т.д. То есть на имеющийся бюджет готовим сайт к будущему росту, чтобы ускорить и упростить будущие процессы.

 

Если задач больше, чем бюджета — договариваемся на увеличение бюджета (если бизнес готов), либо «охлаждаем пыл» и фокусируемся только на важном. Если у бизнеса проблемы, разумеется, мы можем поставить процесс на паузу. Но здесь нужно понимать, что разработчикам требуется время, чтобы отключить сервисы и потом они разойдутся по другим проектам. Когда работы возобновятся, будет необходим повторный онбординг и некоторое время, чтобы собрать нужных людей снова.

 

Но мы слабо верим в полное отсутствие задач на сайте. Это как частный дом: всегда есть, чем заняться. Благодаря фиксированному бюджету и гибкой разработке мы можем:

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

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

Ригидная разработка: фиксирование часов на задачу и штрафы за несоблюдение сроков

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

 

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

 

Звучит справедливо: оценили — делайте за столько, на сколько оценили. Но давайте попробуем переложить такой подход на другую работу.

 

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

 

Или обратная ситуация: вы решили, что у вас бесповоротно сломался счётчик и готовитесь выложить круглую сумму. Но оказывается, что просто отстал провод и всё не так страшно. Электрик либо возьмёт с вас меньшую сумму, либо на оставшиеся деньги проверит/починит розетки/выключатели/свет во всех комнатах.

 

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

1. Мы можем брать в работу только полное ТЗ. Опишите до молекул, что конкретно и где нужно починить. Со стороны заказчика нужен либо грамотный специалист, который в состоянии дать подробное техзадание, либо нужно оплатить время нашего менеджера, который будет уточнять/дополнять/выяснять, что вам нужно. А если окажется, что заказчик не то хотел или хотел не так, то взятки гладки: ТЗ согласовано, мы работали строго по нему. Плюс не получится никаких правок по пути. Простая просьба заодно перекрасить/передвинуть кнопку потребует новых согласований и нового ТЗ.

2. Мы вынуждены закладывать риски. Если кто-то согласен работать с вами в таком формате, значит он уже умножил оценку в 2-3 раза. Никто не будет работать себе в убыток. Мы считаем, что это не очень честно, но в таком случае необходимо покрывать издержки: менеджера, оценщиков, возможные штрафы. Вместо примерной, но более честной оценки мы страхуемся, умножаем часы на задачи и ваши расходы. Нам такой подход не близок. Условное спокойствие только умножает затраты на проект.

3. Мы не заинтересованы в доработке задач. Поймите правильно: если разработчик делает задачу и по пути находит проблему, он не станет её решать в ущерб времени, которое отведено на основную часть работы. Даже если «побочный квест» быстро решается. Теперь он просто скажет, что такая проблема есть и будет ждать согласованного с заказчиком ТЗ.

В итоге мы согласовываем, формализуем, уточняем, оформляем, считаем и прикидываем. А могли бы работать. Куда лучше начать, получить 80% результата, уточнить и доделать.

 

Гибкая разработка подразумевает:

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

Общение с менеджером и руководителями проекта не превращается в череду согласований — это совместная работа людей, заинтересованных в улучшении и развитии сайта.

 

Резюмируем: в таком формате работать можно, но для этого нужно:

 

  • обложить команду менеджерами;
  • оценивать любую фигню;
  • не ждать от нашей команды полной отдачи;
  • принимать факт закладывания рисков.

 

Гибкая разработка + отлаженные годами процессы работы = решение масштабных задач наших клиентов:

 

  • выходить на новые рынки и развивать языковые версии сайта;
  • запускать онлайн-продажи;
  • ускорять работу сайта;
  • обновлять дизайн и добавлять новые и нужные фишки;
  • исправлять любые баги, из-за которых компания несёт убытки

и при этом оставаться в рамках понятного бюджета.

Вывод

Завершим мыслью, с которой начали: сайт — это процесс. Процесс, который должен работать как часы или быть как непрерывный танец, если хотите. Будущее за слаженным союзом бизнеса и команд разработчиков, нацеленных на помощь этому самому бизнесу. Мы в Initlab в этом уверены и всю нашу работу строим на этой основе.