Два вывода за год.
После того как я ушел из Видеоглаза - прошел год. Все это время я занимался тем, что изучал способы ведения различных проектов. За 365 дней я покопался в Консалтинге, поднял Веб-проекты, изучил строительные проекты, разобрался в проектах по ремонтам, потыкался в ИТ-проектах - год был насыщенный. Я успел понять что все что до этого знал - применял не всегда туда, в мире есть еще более чокнутые люди, нельзя экономить на инструменте и многое зависит от команды.
РЕГЛАМЕНТ, ОГРАНИЧЕНИЯ.
Я твердо уяснил, что Проектная деятельность - это не производство (проектов). И как следствие «Регламент проектам вредит». Каждый проект - это живой организм с уникальным набором задач и решений. Регламент просто физически не может описать всех ситуаций, которые могут возникнуть на проекте. В отличии от производства, успех которого зависит от минимизации влияния человека (попросту говоря заменить всех людей роботами и сделать конвейером с минимальными затратами) проектная деятельность держится на Людях. Описать правила для поведения человека в Проекте - все равно что попробовать написать мануал для неудачников по знакомству с женщинами.
Но что-то же должно регулировать работу и помогать руководителям контролировать проекты? На выручку приходят Ограничения - набор допустимых ресурсов на проекте (этапе). Например четкие рамки по времени, бюджету и людям.
Руководитель должен просто четко выставлять ограничения для команды проекта и перестать пытаться контролировать их шаги. Желание контроля и страх стать зависимым приводят к тому, что мы заставляем сотрудников описывать свои действия - рапортовать о расходах, отчитываться о местоположении - короче Босс начинает делать все то, что заставляет сотрудников страдать и мешает нормально работать.
Тут надо понять, что даже если ваш Лучший МегаТоп напишет ахуительный мануал с картинками «Как надо вести проект чтобы все остались довольными»» - следующий за ним менеджер обязательно облажается. Не потому что мануал плохой - а потому что все люди разные. Фиксация «сильных ходов» - дело хорошее, но эти сильные ходы как правило работают только в связке с Хозяином этого Сильного хода. Другой их применить не сможет. Этот факт также делает Регламент - бессмысленным.
После подбора команды, фактически управление проектами сводится:
- постановке целей
- установке ресурсных ограничений (бюджет, время, люди)
- контроль достижения целей и расходов ресурсов.
Все. Не надо контролировать людей - контролируйте результаты их работы. Если человеку комфортно писать код ночью, а днем спать и при этом он сдает работу в срок - пусть так и делает. Если электрику сегодня надо отоспаться и время позволяет - пусть отдыхает. Команда сама найдет свой режим.
ПРОДУКТ ПРОЕКТА = БЭТА+ПОДДЕРЖКА.
В проектной деятельности очень сложно определить конечный продукт - зачастую на выходе мы получим совсем не то, что ожидали. Не, конечно можно постараться описать все риски, учесть все проебы и затраты - но предугадать что в вашу вышку ебанет молния и все пойдет на перекосяк все равно нельзя. Поэтому проекты обязаны быть гибкими. В зависимости от проекта помогает дробление Конечной Цели на промежуточные - технология известная, о ней писать смысла нет.
Я сделал вывод, что многие (как и я в свое время) не понимают что в итоге получает Заказчик. Описать итоговый продукт Проекта - это все равно что описать марсианина. Его никто не видел, но наверно он будет с чем то типа головы и на чем то передвигаться.
Для себя я вывел однозначное понятие продукта любого проекта: бета-версия, с бесплатной поддержкой. Для заказчика формулировку можно придумать и покрасивее конечно. Согласитесь, звучит не очень надежно - но я уверяю вас, внутри команды это работает. Если команда понимает что готовит Бэту версию, она начинает самостоятельно выставлять приоритеты на задачи - вот этот функционал крайне важен, а вот эта пиздюлина не важна и можно доработать потом.
Заказчик всегда отлично относится к бесплатной поддержке - и вы знаете что в период поддержки будете дорабатывать продукт. Команда контролирует период доработки так как знает что надо будет доделать. Для заказчика это выглядит как профессионализм - нифига-себе-как-они-четко-реагируют-и-делают. Да и если вы посмотрите на свои проекты - то наверняка большинство из них будет построено именно по такому принципу. Важно это донести до команды.
Проверьте- работает!
РЕГЛАМЕНТ, ОГРАНИЧЕНИЯ.
Я твердо уяснил, что Проектная деятельность - это не производство (проектов). И как следствие «Регламент проектам вредит». Каждый проект - это живой организм с уникальным набором задач и решений. Регламент просто физически не может описать всех ситуаций, которые могут возникнуть на проекте. В отличии от производства, успех которого зависит от минимизации влияния человека (попросту говоря заменить всех людей роботами и сделать конвейером с минимальными затратами) проектная деятельность держится на Людях. Описать правила для поведения человека в Проекте - все равно что попробовать написать мануал для неудачников по знакомству с женщинами.
Но что-то же должно регулировать работу и помогать руководителям контролировать проекты? На выручку приходят Ограничения - набор допустимых ресурсов на проекте (этапе). Например четкие рамки по времени, бюджету и людям.
Руководитель должен просто четко выставлять ограничения для команды проекта и перестать пытаться контролировать их шаги. Желание контроля и страх стать зависимым приводят к тому, что мы заставляем сотрудников описывать свои действия - рапортовать о расходах, отчитываться о местоположении - короче Босс начинает делать все то, что заставляет сотрудников страдать и мешает нормально работать.
Тут надо понять, что даже если ваш Лучший МегаТоп напишет ахуительный мануал с картинками «Как надо вести проект чтобы все остались довольными»» - следующий за ним менеджер обязательно облажается. Не потому что мануал плохой - а потому что все люди разные. Фиксация «сильных ходов» - дело хорошее, но эти сильные ходы как правило работают только в связке с Хозяином этого Сильного хода. Другой их применить не сможет. Этот факт также делает Регламент - бессмысленным.
После подбора команды, фактически управление проектами сводится:
- постановке целей
- установке ресурсных ограничений (бюджет, время, люди)
- контроль достижения целей и расходов ресурсов.
Все. Не надо контролировать людей - контролируйте результаты их работы. Если человеку комфортно писать код ночью, а днем спать и при этом он сдает работу в срок - пусть так и делает. Если электрику сегодня надо отоспаться и время позволяет - пусть отдыхает. Команда сама найдет свой режим.
ПРОДУКТ ПРОЕКТА = БЭТА+ПОДДЕРЖКА.
В проектной деятельности очень сложно определить конечный продукт - зачастую на выходе мы получим совсем не то, что ожидали. Не, конечно можно постараться описать все риски, учесть все проебы и затраты - но предугадать что в вашу вышку ебанет молния и все пойдет на перекосяк все равно нельзя. Поэтому проекты обязаны быть гибкими. В зависимости от проекта помогает дробление Конечной Цели на промежуточные - технология известная, о ней писать смысла нет.
Я сделал вывод, что многие (как и я в свое время) не понимают что в итоге получает Заказчик. Описать итоговый продукт Проекта - это все равно что описать марсианина. Его никто не видел, но наверно он будет с чем то типа головы и на чем то передвигаться.
Для себя я вывел однозначное понятие продукта любого проекта: бета-версия, с бесплатной поддержкой. Для заказчика формулировку можно придумать и покрасивее конечно. Согласитесь, звучит не очень надежно - но я уверяю вас, внутри команды это работает. Если команда понимает что готовит Бэту версию, она начинает самостоятельно выставлять приоритеты на задачи - вот этот функционал крайне важен, а вот эта пиздюлина не важна и можно доработать потом.
Заказчик всегда отлично относится к бесплатной поддержке - и вы знаете что в период поддержки будете дорабатывать продукт. Команда контролирует период доработки так как знает что надо будет доделать. Для заказчика это выглядит как профессионализм - нифига-себе-как-они-четко-реагируют-и-делают. Да и если вы посмотрите на свои проекты - то наверняка большинство из них будет построено именно по такому принципу. Важно это донести до команды.
Проверьте- работает!