7 шагов к организации разработки в IT-компании

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

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

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

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

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

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

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

В некоторых из них нет необходимости, если проект небольшой – например, в архитекторе или аналитике. Главное: берите профессионалов, на которых сможете положиться и которые в состоянии принять решение по специфичным вопросам. 

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

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

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

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

4. Обеспечиваем команду техническими инструментами

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

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

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

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

5. Планируем работу команды

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

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

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