На прошлой неделе был на конференции Infostart Tech Event. Это одна из крупнейших конференции по 1С. Сообщество 1С сейчас развивается с потрясающей скоростью, там много интересного. Но меня в основном интересовали доклады, не относящиеся напрямую к технологии, а рассказывающие про процессы и организацию работы. Посмотреть удалось не очень много, но вот что я для себя отметил:
1. Удивительно ёмкий доклад Павла Алферова про кризисные проекты. Я вообще не очень люблю рассказы про проектное управление, потому что, во-первых, работа над ИТ-продуктами это не проектная деятельность (а если её подгоняют про проект, то это зачастую ведёт к нехорошим последствиям); а, во-вторых, очень часто проектные ребята совершенно не учитывают содержание проекта и особенности выполнения работ.
Но мимо темы кризисных проектов я не мог пройти — я в принципе много работаю с кризисными проектами.
И тут Павел меня приятно порадовал. Начал он с исследований Standish Group — Chaos Report — с перспективой от 1994 до 2018 годов. Там 46% всех проектов challenged (то есть, были реализованы с отклонениями от начальных сроков, бюджетов или объемов), 19% вообще не были выполнены (это в 2018, в 1994 проваливались 35% проектов). Тут у меня сразу возник вопрос про обусловленность такого успеха — Standish это объясняет распространением практик Agile☝🏻.
Дальше вводится типология кризисных проектов: 1) в которых всё шло хорошо — то есть, проектные усилия были адекватны внешним условиям, но потом случилось что-то катастрофическое и внешние условия резко изменились; 2) в которых проектные усилия мееедленно расходились с внешней средой, и в какой-то момент стало уже поздно; 3) в которых проектные усилия никогда и не находились в соответствии с внешней средой (то есть, изначально обреченные проекты).
Был пример проекта внедрения 1С, в котором по отдельности все подсистемы работали, а вместе никак не соединялись, и вариантов выхода из него. Вариант, на удивление, был "перешли на работу по scrum", кто бы мог подумать-то, а! Про варианты спрашивали у зрителей, предлагая разные варианты действий. База таких вариантов и инструментов есть у автора. (прямо набор практик, как в OMG Essence!)
Проект, естественно, был из разряда "вроде всё шло хорошо, а потом оказалось, что ж*па". И дальше было обсуждение — а как же это на ранних стадиях выявить. Тут интересны две вещи: во-первых, пока заказчик проекта не осознает расхождение между проектными усилиями и внешней средой — бесполезно с ним разговаривать, не поймёт. В примере — если бы заказчику сразу предложили работать по scrum, он бы не согласился: вы же взяли на себя обязательства, ну вот и делайте, зачем ещё мне с вами каждую неделю встречаться и работу вашу проверять?! Дел других нет. То есть, признание руководства, о котором во всех проектных гайдах пишут, это ещё и признание, что проект находится в кризисе, и уже нужно что-то делать. Во-вторых, нужна система контрольных точек (сформулированных в форме объективно наблюдаемого и проверяемого состояния мира), и — вот это новое! — регулярный опрос ключевых вовлеченных в проект лиц по их оценке вероятности достижения следующих контрольных точек в срок. Ну просто как светофор: насколько вы уверены, что в такой-то срок доедем до такой-то точки? Верю, сомневаюсь, совсем не верю. И если будущие точки начали краснеть — это признак подбирающегося кризиса. Более детально метод описан здесь. Инструмент выглядит очень здраво, я сам таким светофором пользовался в одном из проектов ещё лет 15 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).
1. Удивительно ёмкий доклад Павла Алферова про кризисные проекты. Я вообще не очень люблю рассказы про проектное управление, потому что, во-первых, работа над ИТ-продуктами это не проектная деятельность (а если её подгоняют про проект, то это зачастую ведёт к нехорошим последствиям); а, во-вторых, очень часто проектные ребята совершенно не учитывают содержание проекта и особенности выполнения работ.
Но мимо темы кризисных проектов я не мог пройти — я в принципе много работаю с кризисными проектами.
И тут Павел меня приятно порадовал. Начал он с исследований Standish Group — Chaos Report — с перспективой от 1994 до 2018 годов. Там 46% всех проектов challenged (то есть, были реализованы с отклонениями от начальных сроков, бюджетов или объемов), 19% вообще не были выполнены (это в 2018, в 1994 проваливались 35% проектов). Тут у меня сразу возник вопрос про обусловленность такого успеха — Standish это объясняет распространением практик Agile☝🏻.
Дальше вводится типология кризисных проектов: 1) в которых всё шло хорошо — то есть, проектные усилия были адекватны внешним условиям, но потом случилось что-то катастрофическое и внешние условия резко изменились; 2) в которых проектные усилия мееедленно расходились с внешней средой, и в какой-то момент стало уже поздно; 3) в которых проектные усилия никогда и не находились в соответствии с внешней средой (то есть, изначально обреченные проекты).
Был пример проекта внедрения 1С, в котором по отдельности все подсистемы работали, а вместе никак не соединялись, и вариантов выхода из него. Вариант, на удивление, был "перешли на работу по scrum", кто бы мог подумать-то, а! Про варианты спрашивали у зрителей, предлагая разные варианты действий. База таких вариантов и инструментов есть у автора. (прямо набор практик, как в OMG Essence!)
Проект, естественно, был из разряда "вроде всё шло хорошо, а потом оказалось, что ж*па". И дальше было обсуждение — а как же это на ранних стадиях выявить. Тут интересны две вещи: во-первых, пока заказчик проекта не осознает расхождение между проектными усилиями и внешней средой — бесполезно с ним разговаривать, не поймёт. В примере — если бы заказчику сразу предложили работать по scrum, он бы не согласился: вы же взяли на себя обязательства, ну вот и делайте, зачем ещё мне с вами каждую неделю встречаться и работу вашу проверять?! Дел других нет. То есть, признание руководства, о котором во всех проектных гайдах пишут, это ещё и признание, что проект находится в кризисе, и уже нужно что-то делать. Во-вторых, нужна система контрольных точек (сформулированных в форме объективно наблюдаемого и проверяемого состояния мира), и — вот это новое! — регулярный опрос ключевых вовлеченных в проект лиц по их оценке вероятности достижения следующих контрольных точек в срок. Ну просто как светофор: насколько вы уверены, что в такой-то срок доедем до такой-то точки? Верю, сомневаюсь, совсем не верю. И если будущие точки начали краснеть — это признак подбирающегося кризиса. Более детально метод описан здесь. Инструмент выглядит очень здраво, я сам таким светофором пользовался в одном из проектов ещё лет 15 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).