Подходы, которые помогут в ИТ-производстве проекта/продукта

Введение

При реализации любого ИТ-проекта/продукта нам необходимо понимать, что мы делаем, как мы делаем, идём ли мы к цели проекта/продукта. Для этого есть масса подходов — известных и не очень. Мы не будем пытаться выделить самый лучший или самый удобный, а лишь опишем, какой для чего используется. На самом деле это спорный вопрос, и прошу строго не судить, это лишь один из вариантов, не более.

Постановка задачи

Для управления проектом/продуктом нам необходимо отслеживать массу параметров. Мы постараемся сделать небольшой обзор имеющегося инструментария.

Суть подхода

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

Первое направление – заказчик

Для управления взаимоотношениями с заказчиком нам пригодится любой подход по управлению проектами (ПМ стандарт, prince2, PMP). Там указаны дельные вещи, выделю лишь ключевые на мой взгляд:

Цель проекта/продукта
Рамки реализации
Способ отчётности о выполнении работ (тут нам пригодятся вехи проекта)
Бюджет и рамки контракта (не разбиваю на части, так как вопрос очень интересный, и если получится, обязательно его разберу с комментариями юриста)

Второе направление — функциональный заказчик

Разделяем заказчика и функционального заказчика по важному признаку. Пользоваться результатами проекта/продукта и быть заказчиком проекта/продукта – это не одно и то же. При продуктовой разработке функциональный заказчик — это группа людей, которую маркетологи и продуктологи называют целевой аудиторией. Для управления подойдёт практически любой продуктовый подход. Основные моменты:

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

Третье направление — производство ИТ-продукта (разработка)

Для наглядности разделим производство на несколько частей. На мой взгляд, так удобней и понятней. Вы можете действовать как вам удобней. Тут очень полезен набор разных Agile-методик, он позволит нам отслеживать состояние на довольно качественном уровне. Выделю минимальные критерии для достижения успеха:

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

Четвертое направление – тестирование QA

Выделяю его отдельно, так как тестирование QA – это большой комплекс мероприятий по управлению качеством (при возможности сделаю обзор с оценкой специалиста) . Считаю, что QA может и должен подчиняться не начальнику производства, а ответственному руководителю проекта/продукта. Тут пригодятся не свойственные ИТ подходы. Например, ШЕСТЬ СИГМ. Выделим наиболее значимое:

Искренний интерес к клиенту. QA-специалист, в силу своей специфики, это единственный, кто так же, как и пользователь, заинтересован в понимании, что пошло не так: )
Управление на основе данных и фактов. QA может выделять повторяющиеся ошибки и предложить их устранить на этапе проектирования (подчас именно от них исходит инициатива сделать guideline, описать ошибки бизнес-логики, добавить негативные сценарии в use case и т. д.) .
Проактивное (упреждающее) управление. QA может и должен влиять на разработку и аналитику. По факту идёт взаимное обогащение знаниями и опытом.
Взаимодействие без границ (прозрачность внутрикорпоративных барьеров) . QA за счёт анализа своих задач может предложить варианты их количественного и качественного уменьшения.

Пятое направление – инфраструктура и эксплуатация

Выделяю и это направление отдельно, так как задач решается много, а лежат они в разных плоскостях. Тут, я думаю, фаворитом является методология DevOps во всём её многообразии. Не забываем, что простые мирские задачи (хотя они не самые простые) системного администратора тоже сюда входят, куда без них. И помним, что почти каждый системный администратор является junior DevOps (услышал у одного YouTube-блогера, согласен с его позицией) . Выделю задачи, которые отслеживаю:

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

Шестое направление – информационная безопасность

Комментарии излишни. Уверен, каждый из вас понимает важность обеспечения безопасности работы с данными. Тут подойдёт ещё один не свойственный IT подход – ТОС (теория ограничений систем Голдратта) . Если коротко, то это методология управления производством, которая базируется на поиске и влиянии на ограничения систем. В нашем случае критерием оценки будут риски информационной безопасности. По сути мы рассматриваем разрабатываемую систему как набор подсистем, в каждой из которых есть риски безопасности, и работаем всегда с самым узким местом:

Идентификация рисков – тут определяем объекты защиты и угрозы уязвимости
Анализ рисков – вероятность наступления непосредственного риска и возможный ущерб
Методы по работе с рисками – я выделяю в базе 3 из них, остальное это варианты: принять риск (наступит приемлемый для нас ущерб) , передать риск (например, застраховать или отдать подрядчику) , отказ от риска (сменить подход, отказаться от реализации)

Седьмое направление – служба технической поддержки (СТП)

Это направление можно включать в управление проектом/продуктом, а можно не включать. Я считаю, что его необходимо включить, как наиболее качественный источник обратной связи по проекту/продукту. При правильном подходе будет более чем достаточно информации для развития и управления проектом/продуктом. Для работы подойдёт Kanban, но я бы от себя добавил, что в идеальном мире необходимо добавить такой атрибут, как сквозной бизнес-процесс, в рамках которого идут запросы. Основные направления:

Приемка итераций проекта/продукта (возможно, проекта/продукта в целом) – СТП должно в целом знать и понимать, как работать с продуктом (важна документация от разработки, но об этом в следующих статьях) .
Набор обращений пользователей по текущему функционалу – крайне важна статистика обращений и бизнес-процессы, которые затрагивают обращения, причем лучше с кратностью итераций разработки, но можно и реже.
Набор обращений пользователей по развитию проекта/продукта – очень важный момент, так как он позволяет вовлекать пользователя в развитие. Также желательно идти в такт с итерациями развития проекта/продукта.

Выводы

Вместо вывода выделим подходы к IT-производству в целом.

Они объединяют в себе все направления и подходы. При правильном балансе контрольных мероприятий и параметров можно обеспечить качественное управление производственным процессом проекта/продукта:

Заказчик – подойдёт классический подход по управлению проектами. Решает почти все задачи;
Функциональный заказчик – подойдёт продуктовый подход. Он пользуется продуктом (хотя для нас это может быть проект) , который решает его задачи;
Производство ИТ-проекта/продукта (разработка) . Agile – наше всё, подходов множество. Надо выбрать тот, который ближе вам и команде;
Тестирование QA – шесть сигм. Позволит вывести качество на новый уровень и обеспечить обогащение опытом всей команды;
Инфраструктура и эксплуатация – методология DevOps;
Информационная безопасность – ТОС (теория ограничений систем Голдратта) , которая даст комплексный обзор;
Техническая поддержка – Kanban.

Скорее всего вы уже догадались, что для работы есть большой набор подходов. За подход в целом я бы предложил взять ТОС (теория ограничений систем Голдратта) . Он позволит выделить узкое место и настроить весь процесс ИТ-производства. Напомню, что это лишь мой опыт, которым я хотел с вами поделиться.