Команда и ее структура

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

У нас задача на доработку может проходить следующие этапы:

1. Правильная постановка задачи

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

Грамотный аналитик с широким опытом и с хорошей насмотренностью получает достойную оплату труда.

2. Согласования при постановке 

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

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

3. Непосредственно исполнение задачи

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

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

4. Тестирование

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

Только когда команда убедилась, что функционал работает согласно описанию сценария использования - можно перейти к пункту 5.

5. Сдача клиенту

Возможны повторные итерации на этапе сдачи, как и в п. 2. Четкость постановки задачи ускоряет ее последующую сдачу. Однако, даже если первый пункт выполнен качественно, мы все равно сталкиваемся с существенным временем приемки. А время - это всегда деньги специалистов.

6. Перенос на боевой портал и обучение

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

Часто приходится переразворачивать тестовый портал клиента, чтобы убедиться, что новая доработка не конфликтует с предыдущими, встает на правильную версию портала и окружения (php, mysql и пр). 

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

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

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

7. Гарантия и устранение багов

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

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

Как все-таки уменьшить время и стоимость разработки

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