Comments 25
Прям чувствуется боль ФЗ-44.
Да нет, из 300 проектов, наверное, около 200 было просто коммерческих закупок и по 223-ФЗ) это совокупная боль
На самом деле в роли заказчика тут читается любая крупная компания, не столь важно частная или государственная.
Я как-то пересматривал Служебный роман. Самое начало, когда Самохвалов начинается знакомится, дарит сигареты секретарю, выясняет кто с кем дружит, собирает тусовку у себя и так далее. И поймал себя на мысли что ничего не поменялось с тех пор кроме интерьеров. Даже в не государственных корпорациях работают те же самые паттерны поведения.
Спасибо за статью. Подскажите пожалуйста, как можно подтянуть навыки в составлении ТЗ и юридических документов?
ГОСТ34, просто им проникнуться. Очень здорово, что наш гост в отличие от забугорных стандартов описывает этапы создания
Спасибо за комментарий)
Сильно помогает общая насмотренность, можно ориентироваться на ТЗ, которые уже были выполнены вашей компанией. Посидите с аналитиками, посмотрите, как и по каким критериям они оценивают ТЗ, на какие пункты обращают внимание. В идеале нужно понимать, для чего в ТЗ заказчиком оставлена каждая строчка и какую функциональность он планирует получить с помощью этой строчки.
По юридическим документам - юрфак) доводилось править контракты и доп.соглашения, но нужен опыт и лучше все-таки ориентироваться на мнение юристов.
Какую роль вы выполняете в проектах?
Хорошая статья, спасибо.
Знакомы многие моменты, хотя несколько в другой сфере. Близка эта боль, когда паровоз не едет потому что вместо колеи построили вертолётную площадку, и настолько тупик что даже непонятно - плакать или смеяться. Но, тут хотябы со стейкхолдерами заказчика проще, обычно не мешают.
В конечном итоге - МОМ, конфирм ТЗ по мейлу и викли статус - наше душное всё, без этого каша и шапито.
Спасибо! Да, стейкхолдеры, которые воюют только за себя, могут множить хаос кратно. Иногда приходишь на совещание и думаешь, наверное, все-таки я идиот, или там проблемы с ощущением действительности у меня. Невозможно представить, чтобы руководитель, имеющий в своем подчинении 25 тысяч человек, серьезно говорил такое.
какая то слишком очевидная статья. плохо старайтесь не делать, старайтесь делать хорошо и все обговорить заранее. камон камон, стоило ли писать статью?
Ну тогда бы мы не узнали, как сильно автор любит фильм "После прочтения сжечь" ) . А если серьезно, мне кажется нужно определится аудиторией и языком. Статья написана не простым языком (вставки скринов из фильма не спасают) , но видимо для начинающих компаний. У меня по ходу прочтения статьи несколько раз возникало желание переписать базовые советы, простыми словами, чтобы они легко выдерживались из контекста статьи и понимались любым человеком. В целом же хорошая попытка, тема действительно актуальная!
Спасибо! Объем порезал от итогового раза в 3, старался максимально концентрированно подавать информацию. По поводу начинающих компаний - совет про синдром "советской продавщицы", например, написан под впечатлением от большого проекта для регионального правительства и поведения генерального директора одного из лидеров рынка, который устроил скандал на час перед губернатором области)
Хотелось написать под широкий спектр проектов и обсудить опыт, который есть у других людей.
В ходе написания часто ловил себя на мысли, что выступаю Капитаном Очевидность, но:
1) Есть ощущение, что не боги горшки обжигают. Практически у всех в карьере были провальные проекты, мало кто может сказать, что они случились из-за абсолютно и нереально сложных и сверхъестественных вещей. Видел многие проекты, которые хоронили РП с PMP и Prince2 сертификатами, которые не дорабатывали со стейкхолдерами или ТЗ.
2) "Чтобы не попасть в ДТП, достаточно двигаться по дороге на исправной машине и не сталкиваться с другими объектами". Дьявол, мне кажется, как всегда в качестве процесса и способности взглянуть на процесс со стороны.
Я думаю, что в статье в заголовки можно вынести именно советы что делать, а не фиксацию проблемы. Тогда начинающий проект менеджер уже пробежавшись глазами по статье может зацепиться за важное. И желательно давать эти советы простыми словами, например: "Высылайте уведомление об изменении сроков и ТЗ всем представителям заказчика при каждом подобном случае" или "Высылайте уведомление о каждом "чихе" )
Второй совет, это описывать термины при первом использовании, например стейкхолдер.
Спасибо! Один из форматов, о котором думал, статья в духе "50 советов начинающему проджекту". Как думаете, будет спрос? Не будет ощущения, что советы в вакууме, за все хорошее против всего плохого?
В рамках этой статьи хотелось поднять проблему и предупредить о последствиях, а потом дать советы, как проблему сделать контролируемой.
Про стейкхолдеров согласен, лучше определение было перенести на страницу повыше, хоть понятие и общепринятое. Обязательно учту в следующих статьях.
25+ проектов в год, 12 лет, да автор -- мегастахановец
Итого: в ТЗ можно обойтись одной строчкой: "Система должна удовлетворять заказчика"
Заказчики периодически пытаются так сделать для каскадных проектов, но фактически это ТЗ будет бесполезным)
Внутри заказчика есть разные группы стейкхолдеров с разными требованиями к системе, здравомыслящий исполнитель на такое не подпишется и даже если проект в итоге сдадут, проверяющие и контролирующие органы потом по голове погладят всех, и заказчика и исполнителя.
Гибкая разработка и внедрение идеологически решают эту проблему, но для большинства госкорпораций и госухи невозможны.
Насчет одной строчки я иронизирую, конечно. "Гибкая" разработка, если под этим понимать аджайлы и прочий стыд-и-скрам не решают проблему, а переносят её на плечи заказчика (что не так уж и плохо). Попытки действительно решить задачу были в 1990-е, спиральные методики. Но для них нужен высокий уровень организации у самого подрядчика. В общем, все безрадостно пока.
Чтобы проект не был заброшен спустя некоторое время, надо чтобы от результатов внедренного продукта зависел какой-нибудь обязательный бизнес процесс, чтобы пользователи системы не могли не пользоваться вашим продуктом. Но умение правильно выставить такие бизнес процессы это отдельное искусство.
На самом деле, в моем опыте регулярно забрасывали и даже в таком случае. И даже при условии что генеральный директор/владелец требовали обязательно использовать систему. На мой взгляд, тут больше история про "продажу" проекта внутри. Пользователи, по крайней мере критическое большинство, должны понимать важность и ценность системы. Важность и ценность должны быть больше по значимости, чем геморрой от изучения и временные затраты на использование (хотя бы на период, пока пользователи "втянутся"). В идеальном мире инициатор проекта продает проект внутри компании, в реальном мире часто этим приходится заниматься исполнителю.
Спасибо за статью. Было бы классно глянуть на список рекомендуемых автором книг/лекций/иных материалов для изучения базовой базы и разбора кейсов.
Спасибо! Вам для себя или профессиональной деятельности?
Если речь идет о литературе - важно понимать PMBoK, ГОСТ Р ИСО 21500-2014. Если о лекциях - видел курс по проектному менеджменту от Гугла на 6 месяцев, по крайней мере первая часть выглядит здраво и полезно, они приводят примеры кейсов. Для сертификации по PMI есть свой учебный курс. Много книг по проектному управлению, в том числе с кейсами, подборок много, вот на хабре: https://habr.com/ru/articles/683360/
В каждой организации, в которой я работал, были свои регламенты проектного управления, хоть и базирующиеся на ГОСТах/PMBoK и свое обучение для проектных менеджеров, в некоторых компаниях даже были корпоративные университеты, куда они брали в том числе стажеров со стороны. Заказчики периодически выдвигают свои требования по проектному управлению.
Технически, это базовая база, но не то чтобы чтиво на ночь для всех. Уточню в личке цели)
Как не провалить ИТ-проект: заметки менеджера с 12-летним опытом