У нас проект по разработке и внедрению новой ИТ-системы! И нужен ПМ…
Случалось? Куда ж без этого. И вроде бы рынок насыщен всевозможного рода руководителями проектов.
— Выбирай! У всех прекрасный богатый опыт. Есть ПМ-ы с опытом внедрения проектов в Строительстве и Оборонке. Есть ПМ-ы с опытом внедрения медицинских проектов. Есть даже в Авиастроительстве! Что тебе еще надо!? Уровень ответственности и требовательности в этих отраслях – полный отвал башки.
— А он знает ИТ?
— Зачем тебе это?! У него прекрасные знания методологии ведения проектов…это – главное!
И такое тоже случалось…
Давайте разбираться, нужны ли знания в области ИТ руководителю проектов, который должен прийти и организовать разработку и внедрение информационной системы.
Итак, для начала нужно разработать информационную систему!
— Давай, ПМ, что будешь делать сначала?Совсем недавно я столкнулся с подобной историей. С одной стороны, вроде бы все ровно. Действительно, программист знает, из каких этапов обычно состоит разработка. Но, давайте сделаем поправку. Уж чтобы совсем не промахнуться, пойдем к Архитектору! Уж он то должен наверняка знать.
— Определим потребность и цели!
— Хорошо. А потом?
— Нарисуем план проекта по разработке!
— Логично. А из каких этапов состоит разработка? Надо же задачи верхнего уровня для композиции определить!
— Зачем мне это? Спрошу кого-нибудь!
— А кто в ИТ владеет этой информацией?
— Кто-кто? Программист…наверное…
— Привет, Архитектор. Из чего состоит разработка? Нужны задачи в план.Вот так, примерно, происходит, когда ПМ не в курсе.
— Надо взять ТЗ и запилить по нему функционал!
— И все?! Так просто?
— Ну еще протестировать.
— А что, если ТЗ в процессе поменяется?
— Это я не знаю. Мое дело – работать по ТЗ
Сходили. Спросили. Получили 2 пункта: ТЗ и Разработка.
— Что будем делать, ПМ?
— Так все понятно! ТЗ попросим и отдадим Архитектору. Пусть оценит. Скажет срок. Определит точки готовности, а мы его в этих точках будем контролировать. И переодически покзывать пользователю результат.
И что бы мы его спросили, когда брали на работу? А уж если совсем далеко пойти, то Что из себя представляет жизненный цикл Информационной системы от ее рождения до смерти. Хотя, системы не умирают. Они «морально» устаревают.
Никогда не забуду «веселую» историю с системой канального кондиционирования, которая случилась у нас на производстве. Нашли, значит, систему. Хорошую, мощную. Должна был весь завод и прилежащие административные здания охлаждать. Ну купили. За, что-то около 200K американских рублей. Поставили. Ввели в эксплуатацию. После нескольких месяцев работы система загнулась. Почему? Да потому что никакая система не выживет без поддержки и регулярного технического сопровождения!
А ведь информационная система ничем не отличается. Также, как и другие системы, требует ввода в эксплуатацию. Также, как другие – инфраструктуры. И, порой, ошибки внедрения, случившиеся на каком-нибудь проекте по внедрению финансовой системы, обходятся гораздо дороже, чем поломка кондея.
Так как же ПМ, который пришел в ИТ-проект из Авиа или Строительной отрасли сможет нарисовать план, который должен содержать все эти этапы?
Получит консультацию Архитектора? Который фрагментарно видит свою задачу и не представляет, что «до» и что «после»? Увы. Такой проект заранее обречен.
Поэтому, понимание ПМ-а, из каких задач состоит проект, какие задачи являются связанными, а какие можно делать параллельно – архи важно на ИТ-проекте.
И как теперь нам понять, на сколько ПМ соответствует ожидаемому результату? Для этого существует ряд не сложных вопросов, на которые мы должны получить внятные ответы.
Вопрос 1: Из каких этапов состоит формирование технического задания на разработку?
Ответ:
- Из формирования функциональных требований заказчика
- Формирования задания на инфраструктуру, которая, в свою очередь является результатом разработки Контракта по отказоустойчивости и резервному копированию
- И из карты взаимодействия будущей системы с другими системами.
Фактически, мы с вами получаем 3 задания на выходе: функционально-техническое, ТЗ на инфраструктуру, ТЗ на разработку интерфейсов. Они же являются check-point-ами для контроля.
Вопрос 2: Из каких этапов состоит разработка?
Ответ:
- Из распределения задач по разработчикам
- Из формирования плана приемо-сдаточных работ
- Из комплексного тестирования (пилотирования)
- Из создания плана миграции, и разработки этого плана
Вопрос 3: Из каких этапов состоит ввод в эксплуатацию?
Ответ:
- Нагрузочное тестирование
- Формирование методических материалов
- Обучение пользователей
- Заполнение всех НСИ (Нормативно Справочная Информация + доступы пользователей)
- Миграция данных
- Сверка остатков
- Старт операционной работы (пилотирования)
- Hot-assist в период первого запуска
Вопрос 4: Как выглядит схема передачи системы на поддержку, после ввода в эксплуатацию?
Ответ:
Как минимум у системы присутствуют 3 уровня поддержки:
- Инфраструктурная поддержка и мониторинг нагрузки на сервера
- Функциональная поддержка и мониторинг потоков, в случае, если что-то пошло не так в системе.
- Методологическая поддержка, дающая ответы на вопросы, почему это работает так, а не иначе, а также собирающая потребности в эволюциях
И у каждого из этих этапов должен быть свой SLA. Вот тоже словцо, которое не всегда понятно людям вне ИТ.
Если ПМ-кандидат назвал не все этапы – не беда. Мог что-то подзабыть или переволноваться. По мере формирования плана он так или иначе столкнется с ними. Гораздо хуже, если он не будет себе представлять этого абсолютно. Ситуация усложнится, если он начнет проецировать свой предыдущий опыт из других бизнес-сфер на ИТ. В этом случае в команде начнутся конфликты и «падеж» разработчиков. Благо работу технарь себе сможет найти всегда и там, где грамотное управление ИТ-проектом будет его зоной комфорта.
