Dmitriy Kuramshin
Спасибо :)
Не было времени на это xD
Спасибо, Александр :) Каждому свое. Я намеренно не стал уходить в конкретику, т.к. черновой вариант статьи у меня вышел в несколько раз больше. Уж не стал разбивать ее на несколько частей. Я еще подумаю, может потом сделаю еще одну статью-продолжение... а может и не стану))
Все же, решенных задач было очень большое количество - выйдет на отдельную мощную статью)) У меня до сих пор остались некоторые черновые файлы со списком задач антикризисного управления, которые можно ретроспективно разобрать и описать.
По примерам... немного искажаете. Я не увольнял сотрудников и кардинально не менял команду, особенно не нанимая новых. Да, вы абсолютно правы, что онбординг требует времени и обычно затраты выше профита... только к моему кейсу данный пример не очень-то применим, т.к. на протяжении моей работы процесс онбординга прошел лишь у пары сотрудников из ~20 человек. Все остальные уже давно работали в команде и решения принимались вот совсем не на этой основе. В целом, вектор понял, кажется намек на то, что хотелось бы больше примеров данных и количественных/качественных метрик, а также указания определенных триггеров (что заметили, почему это проблема, как решили).
Короче, спасибо за мысли) Рождается идея еще одной прикольной статьи)
Честно говоря, еще ни разу не видел проект, в котором какой-то из фреймворков методологий применяется максимально чисто и с соблюдением всех правил. Да, были очень приближенные варианты и то их можно по пальцем одной руки сосчитать. А повидал действительно очень много, хотя только российский рынок. Но может и не там смотрел)))
Класс! Очень здорово, что такой опыт дал очень позитивный эффект для развития карьеры. Кажется, что это можно считать достойной наградой... хотя в тот момент вряд ли могло так казаться :)
Прям расписать день сложно... Все же у менеджеров он гораздо менее предсказуем и фиксирован, чем у прикладного специалиста. Я попробовал дать достаточно подробный пример распределения времени в комментарии ниже (в этой же ветке), но там не прям день расписан. Подойдет так? или попробовать именно про день рассказать подробнее?
Спасибо большое! ))
По тусовкам, кстати, да! Где-то пару месяцев назад натыкался на очень интересный материал, посвященный как раз тому, что если в компании очень высокий темп работы, риски, деньги, ответственность и т.д., то в этой компании обычно умеют очень хорошо отдыхать. Вроде бы материал был больше шуточный и развлекательный, но доля истины тут наверное имеется :)))
Насколько знаю, многие IT-проджекты саботируют ведение реестра рисков))) Хотя поддерживаю, должное управление рисками как раз и позволяет не завести проект в кризис. Может и не в 100% случаев, но приближенное к нему)
Конечно, гарантий никаких я не имел :) О возможном скачке в карьере я мог только догадываться и рассчитывать, но это действительно ни на что не опиралось. А вот об опыте я знал, т.к. меня привлекал еще сам стэк, да и возможность получить кейс разработки ERP (а не просто ее внедрения) тоже прельщал.
Хотя, честно признаться, наверное тут и правда во всем виноват эфир :)))
План? То есть это планируется? )))
Чет теперь пришла мысль попробовать завести на проекте какой-то свой подобный план. Можно назначить квоты на каждого спеца в команде на количество возможных факапов. Когда квота исчерпана придумать какое-то наказание... геймификация, только очки идут на понижение :))
Интересная мысль, а почему такое предположение? )
Правильно ли я понимаю, что изменение одной переменной является фактическим закрытием текущего проекта и открытием нового?
Например, есть проект А, в процессе реализации которого мы понимаем, что у нас меняется содержание и трудозатраты увеличиваются на 5% (например на 500 000 руб.). Тогда проекта А официально закрывается и запускается проект Б, который является полной копией, но с измененным содержанием и бюджетом n+5% ?
А если меняется не скоуп, а увеличивается команда? На проекте А было 15 человек и в процессе мы решили, что этого мало и добавили еще 5 человек. Проект официально закрывается и открывается проект Б с теми же параметрами, но увеличенной командой?
Лично для меня выглядит немного странно, но не исключаю, что не понял сакральный смысл :)
Верно сказано, по-сути это процессы, определенные компанией для тушения пожаров :) Насколько знаю, антикризисный управлящий как отдельная роль обычно выделяется именно для решения проблем бизнеса. Интересно, а встречали что-то такое именно в контексте проектной деятельности? Может какая-то отдельная роль внутри проектного офиса? )
Спасибо большое! Надеюсь было познавательно и полезно :)
В статье я немного обобщил. В разных компаниях где я работал сам, или просто консультировал по проектной деятельности и процессам, антикризисные меры имели разное представление.
Конкретно у нас был т.н. "антикризисный комитет", который занимался тем, что помогал в решении каких-то сложных вопросов и вытаскиванию проектов из кризисного состояния. это выглядело примерно так:
- Проект попадает в реестр кризисных, за ним закрепляется кто-то из антикризисного комитета;
- Менеджеру проекта назначаются регулярные собрания с комитетом, где он как правило предоставляет определенную отчетность о ходе проекта и динамике изменений. На этих же собраниях менеджер может получать рекомендации и задачи по улучшению ситуации, а также менеджер отчитывается о выполнении подобных антикризисных задач.
- Кроме собраний с комитетом, вместе с закрепленным представителем могут определяться какие-то отдельные задачи для решения кризисной ситуации (провести переговоры, инициировать подписание доп. соглашения, подготовить какое-то предложение) и отдельные встречи с этим человеком;
- Менеджер начинает вести дополнительную специальную документацию на проекте, что-то вроде реестра изменений и подобного. Документация позволяет контролировать ход по антикризисным задачам и отслеживать изменения.
- Плюс есть уже разные процессы и задачи у самого кризисного комитета. Контроль в целом за кризисными проектами внутри компании, распределение ресурсов и каких-то определенных бюджетов на решение проблем. Участие в переговорых процессах с заказчиком (если необходимо) и многое другое.
Спасибо большое! :)
Я сам достаточно глубоко копал в причины совершенных ошибок и искренне удивлялся почему уже зрелая и опытная компания их допустила. Но, как показал мой личный опыт, даже в серьезных и сильных компаниях бывает такая фигня.
На самом деле, бардака в компании не так чтобы много, есть очень классные и регламентированные процессы в части проектного управления. Есть что-то вроде аудиторских проверок проектов и соблюдения методологий, но все же этот проект стал исключением для всей компании )))
Еще раз благодарю за поддержку) Надеюсь, что таких проектов в будущем будет у всех меньше)
Не задумывался об этом. А вообще интересно поднять какую-то статистику об успешности проектов около ERP-шных. Причем интересно посмотреть на успехи внедрения и разработки в отдельности. Может озадачусь этим на днях :) Спасибо за наводку!
Это действительно тяжело, но вполне реально. Главное найти для себя какие-то точки опоры. Лично для меня важна какая-то мотивация... работать на таком проекте просто потому что тебя туда поставили - не приведет ни к чему хорошему))
Кстати хороший пример. Есть знакомые в инвестиционных компаниях, которые часто работают ночами. В консалтинге все тоже очень может быть непредсказуемо и темп работы там очень высокий
Очень сильная история получилась, снимаю шляпу )) А вот что вас мотивировало работать на таком?
Кстати, пришла еще мысль. Если у менеджера очень тяжелый проект и вообще серьезная нагрузка, то можно легко попасть в состояние выгорания и какой-то тотальной прокрастинации.
Для себя я нашел классный способ борьбы - я заставляю себя переключаться. Немного пройтись по улице, сходить в зал или сделать домашнюю тренировку. То есть как-то занять себя больше физически, чем умственно. Не всегда такое получается, но я стараюсь ежедневно такие переключения проводить, это важно для поддержания эффективной работы)))
Это был действительно очень тяжелый период в жизни. Искренне благодарен своей жене за поддержку, понимание и что она сама выдержала это :) Все же для родных и близких это тоже испытание.
Ну поначалу меня точно мотивировало то, что это выглядело как вызов. Проджекты до меня не справились, бизнес не знал что делать и тут есть я, с уже солидным опытом в т.ч. и в ведении данных проектов. Меня привлекал также стэк, т.к. было мало опыта управления подобными проектами, а это кейс в мою копилку. Но вот спустя время это все перестало радовать и я ставил себе целью удержать команду в первую очередь. Тут можно считать, что я больше работал не ради своего руководства, возможных премий и подобного, а я работал именно ради участников нашей команды. И, кажется, мне удалось сколотить очень мощный и крепкий коллектив, где многие работали и поддерживали друг друга. Я просто не хотел подводить свою команду и бросать ее на произвол судьбы... наверное с этими мыслями я доводил уже проект до финала))
Тоже какой-то проект? И что вас побуждает работать, что мотивирует? Интересно)
Мне кажется, такого человека даже встретить сложно. Хотя, есть несколько знакомых предпринимателей, которые работают на износ :)
Кстати нет. Я честно очень рад был тому, что мне удалось сохранить почти всю команду и даже когда проект завершился, многие остались в компании)))
На самом деле, компания далеко не маленькая и давно на рынке. Там сильная и хорошая команда. Возможно, какие-то процессы нуждались в серьезной корректировке, но где не без этого? ) Тут все же была именно проблемная ситуация с самим проектом и очень большим количеством ошибок, которые сам не знаю как пропустили во "взрослой" компании. А подобные проекты встречают повсюду, от какого-нибудь начинающего ИП Смирнов, до Яндекса.
А что именно интересно узнать о процессах? )
Честно и абсолютно ничего не скрывая, могу сказать, что о безнадежных проектах в нашей команде мне неизвестно. Но тут важно сказать, что безнадежные и кризисные проекты - это далеко не уникальный случай. Они есть и встречаются в каждой компании и если мне хоть одна ИТ-компания с достаточно активной проектной деятельностью скажет, что у них такого нет и не было, я не поверю. По официально статистике. которую мне удалось найти (правда это США), усредненно, каждый год в каждой ИТ-компании встречается минимум 1 проект, который может быть трактован как "безнадежный" (т.е. его параметры отклоняются на 50% от нормы). А вот что считать кризисным проектом - тут как правило компании сами внутри для себя это определяют. Мне кажется, что кризисные проекты сейчас есть, но насчет "безнадежных" я не уверен... триггеров я не вижу, поэтому могу считать что таких нет. По крайней мере сейчас.
Безнадежный проект - это термин, предложенный в книге на которую ссылаюсь в статье. И безнадежные проекты действительно встречают и не так редко как хотелось бы. Чтобы не создавать путаницы, авто предложил классный идентификатор - отклонение параметров от нормы не менее чем на 50%.
Проще говоря, если тот же бюджет или срок проекта сокращены вполовину от расчетной нормы, то проект попадает в категорию "безнадежных". А такие ситуации с IT-проектами очень частые. Взять те же гос. или полугос. контракты и там, думаю, можно найти много подобных проектов.
Спасибо :) рад, что понравилось!
Звучит как идея для стартапа))))
Увы, такие проекты встречаются часто. Мне кажется в каждой компании точно найдется по 1 такому :)
Надеюсь, вам удалось его завершить успешно? Интересно, удалось ли сохранить команду? Часто бывало, что команда разваливается.
Заинтересовали. А что побуждало команду продолжать работать на проекте или лично вас? Почему мирились с постоянными переработками?
Лично для себя я отметил очень большую важность именно в работе с мотивацией. Участники команды часто тоже находятся под давление, устают, выгорают. Как я писал, может быть и такое, что единственной радостью в работе остается только удовольствие от работы в конкретной команде, с конкретными людьми...
А как было у вас? Можете рассказать подробнее?
Спасибо большое! Рад, что статья понравилась :)
Как я и писал, уж не знаю почему были совершены такого рода ошибки, т.к. люди уже были очень опытны. Поэтому для меня это стало лишь еще одним очень хорошим подтверждением того, что не важно что у вас за компания, какое имя/бренд/лица или какого уровня проекты, все совершают одни и те же ошибки.
Кстати, очень классно подсветили основные аспекты :)