В продолжение моих предыдущих топиков:
Совет №5. Начинайте строить фундамент.
Как вы помните, ранее, я говорил что любая компания состоит из ПэРов — Продуктов, Проектов, Процессов, с возможностью углубления и рассмотрения дополнительно Профессионалов, Практик и Правил, но мы углубляться так далеко не будем. По моему мнению ИТ компании можно условно разделить на следующие направления, с соответствующим весом ПэРа в деятельности компании:
- Кодеры — компании, которые работают по принципу, проект сдал — проект начал. ПР соотношение: Продукты:25%, Проекты: 60%, Процессы:15%
- Разработчики — компании, которые работают разрабатывают проекты, затем какое то время их поддерживают. ПР соотношение: Продукты:25%, Проекты: 40%, Процессы:35%
- Сопровожденцы — компании, которые работают по сопровождению различных ИТ систем. ПР соотношение: Продукты:25%, Проекты: 20%, Процессы:55%
Каждый из данных блоков, по-моему мнению должен быть достаточно плотно зарегламентирован, в качестве основы можно использовать следующие общепризнанные методики:
- Продукты: элементы ITIL. Для документирования выпуска продуктов, можно взять ИТИЛ за основу, и описать как вы будете готовить и запускать ваши продукты, которые будут получены в результате процессов и проектов. Продукты помогут вам четко характеризовать, что вы выдаете клиентам, в качестве результата вашей операционной и проектной деятельности. При этом я бы не советовал строго следовать ИТИЛ, а использовать его опыт как основу для составления собственной документации.
- Процессы: элементы BPMN. В нашей компании процессы являются краеугольным камнем, от которых пляшет коммерческий офис, так как у нас достаточно много продуктов на поддержке. В процессах необходимо четко описывать как процесс начинается, что в него входит, кто владеет и участвует в процессе, что процесс дает на выходе. Также, что делать если что-то пошло не так. При этом я бы не советовал строго следовать БПМН, а использовать его опыт как основу для составления собственной документации.
- Проекты: элементы PMBOK от PMI. Проекты это основа для создания новых продуктов, услуг. Поэтому крайне важно четко выстроить логику работы проектных команд, их взаимодействия с функциональными подразделениями, управление сроками, бюджетами. PMBOK слишком обширен для нас, так что мы берем только его часть и делаем собственный стандарт для работы с проектами. Самый важный момент нужно помнить что проект всегда ограничен по срокам и всегда нацелен на результат, нельзя путать проекты с процессами.
Вывод для руководителя
Подготовьтесь к написанию большого количества документации. Я предлагаю начать с Процессов, затем перейти к Проектам и закончить Продуктами. В следующих постах я начну рассказывать про каждый раздел. И начнем мы с Библиотеки процессов.
Автор: undry
