От вечно "почти готового" проекта и поиска идеальной РРМ до правил реагирования на правки и "ленивого" саппорта - всё самое интересное, что писали за последнюю неделю про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Проект готов на 90%. Уже полгода
Про те магические 90%, на которых проект способен находиться…очень долго. Причины: РП может сознательно приукрашивать положение дел, исходный объем работ мог быть недооценен, процент готовности мог быть неправильно рассчитан. Но даже и с процентами на руках - никто не знает, "когда закончим?". Процент говорит о прошлом (сколько уже сделано), а срок зависит от того, сколько неопределенности еще маячит впереди: непроверенные интеграции, новые требования, замечания, зависимости от других команд. Поэтому радостные 90% вполне могут соседствовать с еще тремя месяцами работы. Лучше задавать вопрос “а что мы до сих пор не знаем про оставшуюся часть проекта?”.
Пять оттенков PPM: почему идеальной системы для проектного офиса не существует
Автору надоело каждый месяц вручную сводить часы, ставки, замены сотрудников и оставшуюся работу в таблицах, и он пошел смотреть 5 СУП. Но ценен материал, пр.вс., способом сравнения. Берется реальная ситуация: несколько проектов делят специалистов, человек заменяется на более дорогого, объем оставшейся работы меняется, и нужно понять новую загрузку, себестоимость и прогноз завершения. И вот выясняется, что СУПы поддерживают эту цепочку очень по-разному: где-то нужные связи есть изначально, где-то их придется отдельно настраивать. Если близкая тема - почитайте.
Процесс работает, пока руководитель на месте. Ошибки управления через ручное вмешательство
РП уехал на пару дней - и всё стопнулось) Причем люди знают свою работу, задачи заведены, доступы есть. Просто никто кроме рука не знает, какую заявку поставить первой,что допустимо самостоятельно пообещать клиенту и т.п. Пока рук рядом, эта дыра незаметна, т.к.он закрывает ее короткими сообщениями в чате (к примеру). И вот автор показывает, что это на самом деле недоописанная система принятия решений. Лечение - отнюдь не в том, чтобы назначить заместителя, который будет отвечать на те же вопросы. Надо вытащить правила из головы руководителя и формализовать (ну и научить их использовать): кто управляет очередью, какие решения сотрудники принимают сами и в каких случаях действ.
Почему после успешного внедрения становится тяжелее, хотя ожидали, что станет легче
Отличный кейс про формально успешное внедрение, после которого часть сотрудников стала работать больше, а не меньше. Да, новая учетная система дала компании подробные данные, улучшила отчетность, позволила автоматизировать следующие участки, но ради этого сотрудники на входе стали вручную заполнять больше реквизитов. Руководство видит новые возможности, пользователь попискивает из-за доп. действий в каждом документе. Ну и типа обе стороны правы. При том, что необходимость доп данных еще не доказывает, что получать их нужно именно ручным вводом. В общем, после успешного запуска вполне может понадобиться следующий проект, теперь уже по устранению новых проблем.
Как проверить реалистичность квартального плана на примере AI-ассистента
Очень практический разбор, как проверить красивый квартальный план до того, как он превратится в красивый, но проваленный квартальный план)) Дано: 5 сотрудников, 6 двухнедельных периодов и набор работ по ИИ-помощнику. Автор отдельно считает доступное время серверных разработчиков, специалиста по интерфейсу и тестировщика и обнаруживает, что общий объем трудозатрат вроде выглядит терпимо, но вот по конкретным ролям он не помещается. Поэтому из первой версии убираются менее важные части, проверяются зависимости и промежуточные результаты. В итоге рисуется норм план - и норм пример планирования.
Вклад системного аналитика оценивают не по качеству постановки задач разработчикам. А как тогда?
Контур предлагает расширить представление о работе аналитика. Стартовый тезис такой: можно написать прекрасное задание, после которого у разработчиков не останется ни одного вопроса, и потратить несколько месяцев на то, что пользователю вообще не нужно. Поэтому качество работы предлагается оценивать по четырем вещам: понял ли аналитик настоящую проблему, рассмотрел ли несколько вариантов решения, синхронизировал ли участников и появился ли в итоге нужный бизнес-результат. Документ (ТЗ) здесь - средство, а не произведенный результат. И это вообще легко переносится за пределы аналитиков: руководителя проекта тоже негоже оценивать по красоте плана, а продуктового специалиста - по количеству придуманных возможностей. Начинать надо с проверки, правильную ли проблему мы собрались решать.
Хороший материал на границе проекта и продукта. Компания когда-то делала довольно специализированное решение для фармацевтики, а затем стала вытаскивать из отдельных внедрений общую основу, которую можно использовать у следующих заказчиков. Создается устойчивое ядро плюс возможности быстро адаптировать его под специфику клиента. Каждый следующий проект при этом должен отвечать на два вопроса: что здесь действительно уникально, а что пора перенести в общую часть продукта? По данным автора, такой подход сократил средний срок сложного внедрения примерно с восьми месяцев до трех–пяти.
Допустим (а что допускать-то, такое сейчас каждый день), что сервис уже частично прилег, и дежурный на ТП понимает, что сам может не справиться. И тем не менее всё равно пробует еще что-нибудь вместо того, чтобы позвать коллег. Автор выяснил, что проблема часто вовсе не в незнании инструкции. Разбудить человека ночью психологически неприятно, а признать инцидент достаточно серьезным - значит лично принять решение и ответственность. Решение оказалось неожиданно простым: перенести выбор из аварии в спокойное время. Заранее определить уровни инцидентов, для каждого записать, когда и кого нужно привлекать, а спорные случаи потом использовать для уточнения правил. Коротко, если человек должен в стрессовой ситуации принять важное и неприятное решение, часть этого решения стоит принять заранее, пока ничего не горит.
"Сколько я на этом заработаю?" Неправильный вопрос для двух внедрений из трёх
Автор предлагает делить изменения на три типа. 1) дают самостоятельный эффект, их действительно можно оценить отдельно. 2) являются инфраструктурой: сами денег почти не приносят, но без них не работают другие части. 3) звенья цепочки, которые становятся полезными только вместе с соседними изменениями. И вот пытаться для каждого такого звена отдельно посчитать "сколько заработаем" довольно бессмысленно. В одном из примеров автоматизировали продажу билетов, но оставили человеку необходимость вручную подтверждать каждую оплату. Формально почти всё было автоматизировано, а практически без толку, тк организатор всё равно должен постоянно сидеть у экрана и в итоге возвращается к старому способу.
Заказчик изменил требование посреди разработки. Как понять, что придётся переделывать
Практическая инструкция на случай классической ситуации “тут небольшое изменение”. Пример: команда уже реализует согласование заявок, а заказчик внезапно добавляет новый уровень согласования и возможность возвращать отклоненную заявку на повторный круг. Автор предлагает не переписывать старое требование задним числом и не называть новый срок с ходу. Сначала изменение фиксируется отдельно, затем сравнивается старое и новое поведение, выясняется причина изменения и проходятся все зависимости: данные, правила, интерфейсы, проверки, уже сделанная работа. Важный момент: сообщение заказчика о новом пожелании еще не означает автоматического принятия командой нового объема. Только после оценки можно решать - включать изменение сейчас, переносить дальше или менять срок.