Введение
При реализации любого ИТ-проекта/продукта нам необходимо понимать, что мы делаем, как мы делаем, идём ли мы к цели проекта/продукта. Для этого есть масса подходов — известных и не очень. Мы не будем пытаться выделить самый лучший или самый удобный, а лишь опишем, какой для чего используется. На самом деле это спорный вопрос, и прошу строго не судить, это лишь один из вариантов, не более.
Постановка задачи
Для управления проектом/продуктом нам необходимо отслеживать массу параметров. Мы постараемся сделать небольшой обзор имеющегося инструментария.
Суть подхода
Начнём с описания всего процесса, от идеи до эксплуатации. Для этого воспользуемся направлениями, которые нам необходимо отслеживать, и наполним их подходами.
Первое направление – заказчик
Для управления взаимоотношениями с заказчиком нам пригодится любой подход по управлению проектами (ПМ стандарт, 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.
Скорее всего вы уже догадались, что для работы есть большой набор подходов. За подход в целом я бы предложил взять ТОС (теория ограничений систем Голдратта) . Он позволит выделить узкое место и настроить весь процесс ИТ-производства. Напомню, что это лишь мой опыт, которым я хотел с вами поделиться.