Вы знаете, я всегда за критику, но вы говорите о плохом менеджменте. хотя по факту статьи вы не сказали вообще ничего. По сути вы сделали ничем не подтвержденный переход на личности.
Если есть что сказать по сути проблемы - скажите, иначе не смогу поддержать дискуссию.
Я оценил вашу иронию, но, действительно, у меня есть канал для менеджеров на котором я не зарабатываю, а который я использую для обсуждения тенденций и проблем в управлении в ИТ. Ничего плохого в том, что я даю на него ссылки не вижу.
А вы по сути согласны или нет, расскажите, и почему?
хорошая история, ваш тезис я тоже и слышал, и читал тут, у нас на Хабре.
Давайте я попробую не оппонировать вам, а ответить, что я про это думаю. То есть именно в порядке обмена опытом.
Я, на основании личного опыта, умею оценивать проекты на несколько сотен млн рублей и попадать в оценку по фактическим трудозатратам с точностью до 0.5% (да, есть такой пример в жизни). Но я делаю это основываясь на неявных и неформализованных критериях, которые называются "Экспертная оценка". Формализовать в регламент это я не умею. Если умеете вы - поделитесь таким регламентом. Особенно с учетом того, что я тоже работаю в заказной разработке в куче разных областей и не вижу, как это поддается формализации. Очень интересно, правда
можно даже для интереса рассмотреть проект по созданию какой нить внутренней системы предприятия для обработки заявок, интегрированной с биллингом, HR системой и парочкой других, чтобы понять, а как вы формализуете ее оценку?
Я понимаю, что мы с вами можем вообще говорить о разном: говоря об оценке, я понимаю, что есть минимум три оценки, которые делаю в больших проектах я:
предварительная - на основании бизнес требований
уточненная - на основании уточненных требований, ограничений и допущений
детальная - на базе декомпозиции требований командой разработки
в этой парадигме оценка от исполнителей появится только в части 2 или 3. Но и в части 1 я считаю важным привлекать ответственного от техблока. Принципиально это важно, поскольку тогда разработчики несут ответственность за решение. Это именно делегирование ответственности в команду и командная игра. Да, менеджер может сделать все сам (тем более лучше выйдет), но это классика делегирования: один в поле по итогу воин хуже, чем команда. А когда команда или ТехДир или Лид дают оценки, они берут на себя часть ответственности за техническое решение, что есть правильно с тз оргструктуры проекта. Вы согласитесь или покритикуете такой подход?
Я так не считаю. Согласен в части "многие затраты непредсказуемы", но очень важно не потерять суть за частными проблемами: сложность планирования планирования не должна отменять. Зато если я оцениваю сам (а на высоком уровне я умею оценивать вполне), я не делегирую часть ответственности своей команде. Что позже может привести к проблемам посерьезнее: срыву сроков и ругани в команде. Я с таким сталкивался не раз, когда сейлзы продавали, а тех команда потом ругалась, почему не позвали на оценку проекта??
А расскажите как вы делаете именно, интересно? По пулу задач из трекера с усреднением или как то хитрее? И для каких проектов у вас это работает?
да уж куда там. по опросам до сих пор - самый популярный ИСУП это "самописная система", затем MSP, затем JIRA. На рынке полный бардак, что подтверждает результат опроса под статьей.
Я не просто знаю десятки вполне профессиональных РП, которые в глаза не видели PMBoK и при этом успешно внедряют, но и сам таким был долго.
PMBoK - просто справочник, который не дает ответа на обычные вопросы РП:
как затащить невозможное
как устранить хаос
как сделать так, чтобы заказчик был доволен
как выжить на проекте
Указанные книги стараются ответить именно на эти вопросы. Управление проектами вообще больше софтскилловая область, нежели хардовая. Невозможно хорошо делать проекты, прочитав ПМБоК. А вот делать хорошо проекты, не читая его - можно.
в целом норм, можно почитать. Хотя обзора классики типа Как пасти котов, Мифический человекомесяц, Критическая Цепь и нового для Росссийского рынка: Черная книга менеджера тут нет.
И понять не могу: толи методология вообще никакая, что под нее можно подпихнуть любой проект, выполняемый в режиме "завели карточку проекта, согласовали старт, далее ежедневно мониторим проблемы и изменения, еженедельно статус и продвижение по плану, ежемесячно собираемся с проектным комитетом, пока не закончим или пока не отменим"
Но так то в PRINCE2 тоже есть проверка на необходимость продолжения проекта.
ПМБоК в целом позволяет делать все вышеописанное (он вообще достаточно вольный)
В чем фишка P3express?
риски? но про работу с рисками я писал у себя (и даже собирал фидбек с РПшников) - до крупных проектов с 20-40 человеками в команде, это почти всегда вырождается в формалистику. Приведенный вами риск про ожидания - отличный пример. Он есть вообще всегда, шаги по его митигации РП выполняет всегда (а если нет, это плохой РП), так зачем ради этого рожать бюрократию?
короткий бриф проекта? ну ребят, это может быть паспорт проекта в вольной форме - тоже самое.
ревью сторонним РП твоего проекта? Ну тут сама методология пишет, что надо доверие в команде, чтобы РП честно говорил, что не так. Не очень верю в это. тут бы интересно почитать, какие замечания ребята друг другу пишут и как им такая иннициатива
итого: без наезда, просто хочу понять, зачем p3 express а не просто: делать проектный план, резать на спринты и точно также работать с проблемами и рисками каждый день, обновлять план почаще, и собираться со спонсорами по необходимости?
6 лет назад в одной небольшой компании слишком доверились Яндекс хостингу. И когда тот в конце апреля 2019 упал, убив часть клиентских данных, там точно также восстанавливали тикеты через парсинг почтовых уведов. Каменты пропали, конечно, но лучше так))
у меня товарищ (у него 5 и 1 год детям) в прошлые майские имел траурное настроение: "блин, праздники - это ужас, я не могу уйти на работу, они на меня бросаются целый день")))))))
Лайк за тему автору. Женщин в айтишке все больше и тема правда важная, знаю как многодетный отец и муж жены айтишницы. Да и много девчонок вокруг меня, и сам я набирал женщин из декрета.
Мои дополнения
Можно запросто выйти на полставки. Зависит от вашей роли, но вот аналитику найти 0.5 ставки - нет проблем.
Женщинам, которые считают что они все забыли за время декрета - девочки, это ваш перфекционизм. Профессионализм не теряется и за 10 лет. Я взял на работу отличного аналитика, она 7 лет в декрете сидела.
Женщина, вышедшая из декрета - находка для работодателя))) обычно девчонки офигевают от домашних дел и берутся за работу с горящими глазами :)
мораль: ничего страшного в декрете нет, бояться не надо, в айти полно вакансий и если вы не дурак, работа найдется :))
по динамике: неясно как это делать? Тогда все задачи должны быть типовые в стиле "все по 8 часов" наверное? Иначе: у меня 3 задачи, одна на 40 часов, одна на час, одна на 24 часа. Вот будет динамика на неделю. Если вы про другое - поясните, интересно разобраться. Я собственно свою статью готовлю про списания и оценки, вот, читаю мнения.
Таймшиты для клиентов одно, там зависит от клиента и там можно заниматься творчеством, как правило (плюс/минус). Важнее внутренний учет себестоимости внедрения. Пример: есть компания, в ней есть ИТ отдел. Он жрет ФОТ. Нехилый такой, самые большие зарплаты там. Туда приходят проекты, делаются за фиг пойми какие деньги. И я , как бизнес, не понимаю: вот мне сделать фичу, которая принесет миллион, имеет смысл через наше айти или лучше вообще не делать? или отдать на подряд? Да, эстимейт мне айтишники дают, а как проверить, что они не соврали? Одна из больших проблем внутренних проектов компаний, которые я вижу - никто не проверяет ФЭО (он же бизнес кейс) после внедрения: а наскально обещанный экономический эффект имеет место?
Когда одна группа работает годами - 100% да, списание нафиг не надо. Там просто вешаем весь ФОТ на один проект и все. Но такое есть редко. И даже один большой проект (или продукт и его развитие) как правило, желательно разрезать на кусочки, чтобы следить за эффективностью работы
Да, я как раз про случаи, когда несколько проектов на одну команду или несколько фич в рамках одного продукта, бабки по которым надо посчитать раздельно
кроме вашего шефа и СЕО компании, которые совершенно не понимают, как оценить то, что делает демократическое айти :)
Почему я позволяю так себе сказать: я видел компании , где пытались ввести учет времени и знаю, для чего это делалось.
Грубо говоря, там СЕО категорически не понимает, что делает команда, все проекты непрозрачны, сколько тратится денег на каждый - неясно.
Получает за это по башке ваш руководитель. Он же пытается как то наладить работу и учет времени - нормальный шаг. Но если начальник слабый, его сотрудники шлют лесом, а потом просто увольняют.
А если не увольняют, то особой проблемы и не было :)
ИИ фиг поможет именно потому, что он учтет, что сотрудник прокрастинировал 4 часа, потом вообще ушел куда то (а в чате в ТГ ИИ найдет, что он позвал всех на обед, который затянулся), а потом за 2 часа все сделал.
При этом оценка была на день и списаны 8 часов.
Тут нет ответственности сотрудника, а ИИ как нянька имхо получается.
Джуну не поможет, добавит стресса, синьора бесить будет.
Тут меня больше зацепило не то, что вы автоматизировали совершенно обезьянью работу - это нормально.
Тут, скорее удивляет, что в 24 году один из лидеров рынка СИ пишет, что собирает факт через старый добрый эксель-таймшит. Да еще и гордится тем, что автоматизирует агрегацию этих экселей. Коллеги, вы не рассматривали вариант централизованного учета факта через тикет трекеры, которые у вас на 100% есть и используются?
Почему? Это же автоматически
устранит вообще необходимость собирать и агрегировать - все будет автоматом
сделает ваш факт не фейком (потому что в таймшит народ списывает ровно столько, сколько от них хотят, к реальной эффективности это отношения не имеет), а реальным фактом
изза п2 вы увидите реальную утилизацию, которая у вас будет процентов 50% и на основании этого вы прекратите найм, нагружая тех, у кого нет работы и секономите много денег)
Вы получите реальный планфактный анализ онлайн. А не раз в неделю :)
Вы секономите на администраторах проектов, пусть лучше ребята станут джунами РП, а не будут эксельки гонять туда-сюда
А оценка атомарных задач к оценке общей не имеет отношения в вашей методологии?
В моем понимании (почему и спрашиваю):
Оценка атомарная сама по себе никому не нужна, всех интересуют сроки. И в статье выше речь про сроки, которые даются на основании прогнозирования исполнения атомарных задач.
для меня естественно, когда высокоуровневые оценки делает, условно скажем, тех лид.
Но далее , при более детальной декомпозиции, все задачи оцениваются непосредственными исполнителями. Для чего это надо - я написал в комментарии к статье: каждый берет ответственность за свой небольшой объем. Если оценка превышает ту, что дал лид в первоначальном виде, это повод уже лиду обсудить с командой, что не так (далее или лид признает косяк или исполнитель соглашается с лидом.
Таким образом получаем равномерное распределение ответственности по команде, каждый отвечает за свое и учится своему (и отвечает не только РП, с которого спросили оценку)
тогда прошу вас, поясните, что вот тут вы имели в виду: а вообще зачем оценивать время выполнения задачи? Ведь стоимость проекта мы так не определяем. Как вы определяете стоимость проекта?
Ну и подвопрос: если вы его определяете без учета оценок от исполнителей, каким образом вы страхуете риск превышения бюджета и сроков и демотивации команды (которая сроков не давала, а их директивно спустили сверху)?
Вы знаете, я всегда за критику, но вы говорите о плохом менеджменте. хотя по факту статьи вы не сказали вообще ничего. По сути вы сделали ничем не подтвержденный переход на личности.
Если есть что сказать по сути проблемы - скажите, иначе не смогу поддержать дискуссию.
Спасибо.
Я оценил вашу иронию, но, действительно, у меня есть канал для менеджеров на котором я не зарабатываю, а который я использую для обсуждения тенденций и проблем в управлении в ИТ. Ничего плохого в том, что я даю на него ссылки не вижу.
А вы по сути согласны или нет, расскажите, и почему?
хорошая история, ваш тезис я тоже и слышал, и читал тут, у нас на Хабре.
Давайте я попробую не оппонировать вам, а ответить, что я про это думаю. То есть именно в порядке обмена опытом.
Я, на основании личного опыта, умею оценивать проекты на несколько сотен млн рублей и попадать в оценку по фактическим трудозатратам с точностью до 0.5% (да, есть такой пример в жизни). Но я делаю это основываясь на неявных и неформализованных критериях, которые называются "Экспертная оценка". Формализовать в регламент это я не умею. Если умеете вы - поделитесь таким регламентом. Особенно с учетом того, что я тоже работаю в заказной разработке в куче разных областей и не вижу, как это поддается формализации. Очень интересно, правда
можно даже для интереса рассмотреть проект по созданию какой нить внутренней системы предприятия для обработки заявок, интегрированной с биллингом, HR системой и парочкой других, чтобы понять, а как вы формализуете ее оценку?
Я понимаю, что мы с вами можем вообще говорить о разном: говоря об оценке, я понимаю, что есть минимум три оценки, которые делаю в больших проектах я:
предварительная - на основании бизнес требований
уточненная - на основании уточненных требований, ограничений и допущений
детальная - на базе декомпозиции требований командой разработки
в этой парадигме оценка от исполнителей появится только в части 2 или 3. Но и в части 1 я считаю важным привлекать ответственного от техблока.
Принципиально это важно, поскольку тогда разработчики несут ответственность за решение. Это именно делегирование ответственности в команду и командная игра.
Да, менеджер может сделать все сам (тем более лучше выйдет), но это классика делегирования: один в поле по итогу воин хуже, чем команда. А когда команда или ТехДир или Лид дают оценки, они берут на себя часть ответственности за техническое решение, что есть правильно с тз оргструктуры проекта.
Вы согласитесь или покритикуете такой подход?
Я так не считаю. Согласен в части "многие затраты непредсказуемы", но очень важно не потерять суть за частными проблемами: сложность планирования планирования не должна отменять.
Зато если я оцениваю сам (а на высоком уровне я умею оценивать вполне), я не делегирую часть ответственности своей команде. Что позже может привести к проблемам посерьезнее: срыву сроков и ругани в команде. Я с таким сталкивался не раз, когда сейлзы продавали, а тех команда потом ругалась, почему не позвали на оценку проекта??
А расскажите как вы делаете именно, интересно? По пулу задач из трекера с усреднением или как то хитрее? И для каких проектов у вас это работает?
Это само собой)
да уж куда там. по опросам до сих пор - самый популярный ИСУП это "самописная система", затем MSP, затем JIRA. На рынке полный бардак, что подтверждает результат опроса под статьей.
Я не просто знаю десятки вполне профессиональных РП, которые в глаза не видели PMBoK и при этом успешно внедряют, но и сам таким был долго.
PMBoK - просто справочник, который не дает ответа на обычные вопросы РП:
как затащить невозможное
как устранить хаос
как сделать так, чтобы заказчик был доволен
как выжить на проекте
Указанные книги стараются ответить именно на эти вопросы. Управление проектами вообще больше софтскилловая область, нежели хардовая. Невозможно хорошо делать проекты, прочитав ПМБоК. А вот делать хорошо проекты, не читая его - можно.
это просто справочник. от ее прочтения у вас закружится голова, так много там аббревиатур. И они все сразу вам понядобятся примерно никогда.
Это я говорою, как РПО с 20 летним опытом внедрения разных проектов.
Но как справочник - норм. Важных вещей типа: как говорить с заказчиком, как не факапить, вы оттуда не узнаете. Да и мало откуда узнаете вообще
в целом норм, можно почитать. Хотя обзора классики типа Как пасти котов, Мифический человекомесяц, Критическая Цепь и нового для Росссийского рынка: Черная книга менеджера тут нет.
Вот я читал и самого Дмитрия и вашу статью читаю.
И понять не могу: толи методология вообще никакая, что под нее можно подпихнуть любой проект, выполняемый в режиме "завели карточку проекта, согласовали старт, далее ежедневно мониторим проблемы и изменения, еженедельно статус и продвижение по плану, ежемесячно собираемся с проектным комитетом, пока не закончим или пока не отменим"
Но так то в PRINCE2 тоже есть проверка на необходимость продолжения проекта.
ПМБоК в целом позволяет делать все вышеописанное (он вообще достаточно вольный)
В чем фишка P3express?
риски? но про работу с рисками я писал у себя (и даже собирал фидбек с РПшников) - до крупных проектов с 20-40 человеками в команде, это почти всегда вырождается в формалистику. Приведенный вами риск про ожидания - отличный пример. Он есть вообще всегда, шаги по его митигации РП выполняет всегда (а если нет, это плохой РП), так зачем ради этого рожать бюрократию?
короткий бриф проекта? ну ребят, это может быть паспорт проекта в вольной форме - тоже самое.
ревью сторонним РП твоего проекта? Ну тут сама методология пишет, что надо доверие в команде, чтобы РП честно говорил, что не так. Не очень верю в это. тут бы интересно почитать, какие замечания ребята друг другу пишут и как им такая иннициатива
итого: без наезда, просто хочу понять, зачем p3 express а не просто: делать проектный план, резать на спринты и точно также работать с проблемами и рисками каждый день, обновлять план почаще, и собираться со спонсорами по необходимости?
6 лет назад в одной небольшой компании слишком доверились Яндекс хостингу. И когда тот в конце апреля 2019 упал, убив часть клиентских данных, там точно также восстанавливали тикеты через парсинг почтовых уведов. Каменты пропали, конечно, но лучше так))
Как то ни о чем.
хоть бы написали о том, как куча компаний пытаются заменить JIRA.
100% ))
у меня товарищ (у него 5 и 1 год детям) в прошлые майские имел траурное настроение: "блин, праздники - это ужас, я не могу уйти на работу, они на меня бросаются целый день")))))))
Лайк за тему автору. Женщин в айтишке все больше и тема правда важная, знаю как многодетный отец и муж жены айтишницы. Да и много девчонок вокруг меня, и сам я набирал женщин из декрета.
Мои дополнения
Можно запросто выйти на полставки. Зависит от вашей роли, но вот аналитику найти 0.5 ставки - нет проблем.
Женщинам, которые считают что они все забыли за время декрета - девочки, это ваш перфекционизм. Профессионализм не теряется и за 10 лет. Я взял на работу отличного аналитика, она 7 лет в декрете сидела.
Женщина, вышедшая из декрета - находка для работодателя))) обычно девчонки офигевают от домашних дел и берутся за работу с горящими глазами :)
мораль: ничего страшного в декрете нет, бояться не надо, в айти полно вакансий и если вы не дурак, работа найдется :))
по динамике: неясно как это делать? Тогда все задачи должны быть типовые в стиле "все по 8 часов" наверное? Иначе: у меня 3 задачи, одна на 40 часов, одна на час, одна на 24 часа. Вот будет динамика на неделю. Если вы про другое - поясните, интересно разобраться. Я собственно свою статью готовлю про списания и оценки, вот, читаю мнения.
Таймшиты для клиентов одно, там зависит от клиента и там можно заниматься творчеством, как правило (плюс/минус). Важнее внутренний учет себестоимости внедрения. Пример: есть компания, в ней есть ИТ отдел. Он жрет ФОТ. Нехилый такой, самые большие зарплаты там. Туда приходят проекты, делаются за фиг пойми какие деньги. И я , как бизнес, не понимаю: вот мне сделать фичу, которая принесет миллион, имеет смысл через наше айти или лучше вообще не делать? или отдать на подряд? Да, эстимейт мне айтишники дают, а как проверить, что они не соврали?
Одна из больших проблем внутренних проектов компаний, которые я вижу - никто не проверяет ФЭО (он же бизнес кейс) после внедрения: а наскально обещанный экономический эффект имеет место?
Когда одна группа работает годами - 100% да, списание нафиг не надо. Там просто вешаем весь ФОТ на один проект и все. Но такое есть редко. И даже один большой проект (или продукт и его развитие) как правило, желательно разрезать на кусочки, чтобы следить за эффективностью работы
Да, я как раз про случаи, когда несколько проектов на одну команду или несколько фич в рамках одного продукта, бабки по которым надо посчитать раздельно
кроме вашего шефа и СЕО компании, которые совершенно не понимают, как оценить то, что делает демократическое айти :)
Почему я позволяю так себе сказать: я видел компании , где пытались ввести учет времени и знаю, для чего это делалось.
Грубо говоря, там СЕО категорически не понимает, что делает команда, все проекты непрозрачны, сколько тратится денег на каждый - неясно.
Получает за это по башке ваш руководитель. Он же пытается как то наладить работу и учет времени - нормальный шаг. Но если начальник слабый, его сотрудники шлют лесом, а потом просто увольняют.
А если не увольняют, то особой проблемы и не было :)
ИИ фиг поможет именно потому, что он учтет, что сотрудник прокрастинировал 4 часа, потом вообще ушел куда то (а в чате в ТГ ИИ найдет, что он позвал всех на обед, который затянулся), а потом за 2 часа все сделал.
При этом оценка была на день и списаны 8 часов.
Тут нет ответственности сотрудника, а ИИ как нянька имхо получается.
Джуну не поможет, добавит стресса, синьора бесить будет.
Тут меня больше зацепило не то, что вы автоматизировали совершенно обезьянью работу - это нормально.
Тут, скорее удивляет, что в 24 году один из лидеров рынка СИ пишет, что собирает факт через старый добрый эксель-таймшит. Да еще и гордится тем, что автоматизирует агрегацию этих экселей. Коллеги, вы не рассматривали вариант централизованного учета факта через тикет трекеры, которые у вас на 100% есть и используются?
Почему? Это же автоматически
устранит вообще необходимость собирать и агрегировать - все будет автоматом
сделает ваш факт не фейком (потому что в таймшит народ списывает ровно столько, сколько от них хотят, к реальной эффективности это отношения не имеет), а реальным фактом
изза п2 вы увидите реальную утилизацию, которая у вас будет процентов 50% и на основании этого вы прекратите найм, нагружая тех, у кого нет работы и секономите много денег)
Вы получите реальный планфактный анализ онлайн. А не раз в неделю :)
Вы секономите на администраторах проектов, пусть лучше ребята станут джунами РП, а не будут эксельки гонять туда-сюда
Почему вы это до сих пор не сделали?
слишком общее, слишком ни о чем.
для начала - учет времени через таймшиты не дает корректного факта вообще.
Ага, спасибо.
А оценка атомарных задач к оценке общей не имеет отношения в вашей методологии?
В моем понимании (почему и спрашиваю):
Оценка атомарная сама по себе никому не нужна, всех интересуют сроки. И в статье выше речь про сроки, которые даются на основании прогнозирования исполнения атомарных задач.
для меня естественно, когда высокоуровневые оценки делает, условно скажем, тех лид.
Но далее , при более детальной декомпозиции, все задачи оцениваются непосредственными исполнителями. Для чего это надо - я написал в комментарии к статье: каждый берет ответственность за свой небольшой объем. Если оценка превышает ту, что дал лид в первоначальном виде, это повод уже лиду обсудить с командой, что не так (далее или лид признает косяк или исполнитель соглашается с лидом.
Таким образом получаем равномерное распределение ответственности по команде, каждый отвечает за свое и учится своему (и отвечает не только РП, с которого спросили оценку)
тогда прошу вас, поясните, что вот тут вы имели в виду: а вообще зачем оценивать время выполнения задачи? Ведь стоимость проекта мы так не определяем. Как вы определяете стоимость проекта?
Ну и подвопрос: если вы его определяете без учета оценок от исполнителей, каким образом вы страхуете риск превышения бюджета и сроков и демотивации команды (которая сроков не давала, а их директивно спустили сверху)?