Котел ПМа

2021-11-05 15:55:01 ​​#менеджменткакискусство

Когда клиент обещал прислать подробную спецификацию, а прислал три строчки текста.

Виктор Васнецов, «Витязь на распутье», 1882 Відкрити / Коментувати

2021-11-02 16:25:16 ​​ Сел и поехал. О готовых решениях и их лицензиях.

Нельзя же каждый день изобретать велосипеды! Долго, дорого, неэффективно.
Допустим, клиент попросил добавить в продукт текстовый редактор.
Представляете, сколько времени и усилий уйдет создать все эти стили, форматы, шрифты, списки, возможность вставлять таблицы, тэги, ссылки, проверки спеллчекером и т.д.?
Тысячи часов на создание функционала, который уже столько раз был создан до нас!

Понятный и вроде бы разумный выход лежит на поверхности — использовать готовое решение в нашем продукте . Однако, поторопившись с выбором и не изучив досконально лицензии, мы можем навлечь беду на бизнес нашего клиента

Лицензии на чужой софт бывают разных типов, и их использование может требовать от клиента выполнения условий, к которым он был не готов.
Например, использование компонента с типом лицензии GPL может заставить открыть код продукта, который мы разрабатываем
Другие производители могут выставить как обязательное условие покупку именной лицензии для разработчиков. Или покупку индивидуальной лицензии для каждой копии вашего продукта, частью которого теперь становится их библиотека.

Поэтому предлагать клиенту приобрести какое-то готовое решение, основываясь только на его функционале было бы опрометчиво. Важно разобраться с лицензированием, посчитать стоимость использования этого компонента/фреймворка/библиотеки, изучить альтернативы и озвучить клиенту риски, если они есть

Признаюсь честно, каждый раз, когда мне приходится читать текст лицензий, этот процесс меня вгоняет в тоску Хорошо, что указание типа лицензии сходу отвечает на многие вопросы, а дальше для прояснения непонятных юридических оборотов можно подключить к вопросу юристов.
Кроме того, часто авторы платных библиотек не указывают сразу цены, и их еще нужно добыть у службы поддержки, рассказав о вашем софте и его использовании.
Так что это тот еще квест с подключением разных специалистов, длительными переписками или созвонами с сейлзами платных библиотек.
Квест, где победой может быть быстрое и эффективное решение бизнес задачи. Поэтому игра своих свеч стоит


Отставлю несколько источников, где можно почитать про типы лицензий:
What Is a Software License? 5 Types of Software Licenses You Need to Know About
5 types of software licenses you need to understand
Code Project: Licenses Відкрити / Коментувати

2021-10-28 15:59:56 ​​Фабрика по производству Middle PM-ов. Часть III

Я хочу этим постом выступить в поддержку Junior ПМ-ов.

Я точно знаю, что не существует фабрики по производству Middle ПМ-ов, мы все начинали с малого и учились на реальных клиентах и командах.

Что можно сделать, чтобы быстрее получить боевой опыт и наломать меньше дров?

Учиться. Хорошо бы войти с багажом обширных знаний в области управления проектами.
В бою уже сложнее найти время на прохождения курсов, лучше на старте работы знать, где и какую информацию искать, какие инструменты бывают и для чего используются.

Прокачать английский. И клиентов быстрее поймете, и письма будет легче писать, и нюансы будете схватывать на лету.

Получить опыт управления людьми. Эта работа сильно про людей. Важно понимать, что это ваше и уметь с людьми договариваться, мотивировать их, решать конфликты и т.д.

Настроиться, что будет непросто, будет много обратной связи, и на ней вы сможете быстрее научиться.

Зачастую Junior ПМ начинает с роли помощника руководителя на каком-то большом проекте в теневом режиме. Там есть возможность попрактиковаться вести некоторые внутренние встречи, писать документы и письма . Позже можно получить в ответственность отдельные зоны: например, контроль за прогрессом, сбор метрик, работу с требованиями и т.д.

После такого опыта и постоянных наблюдений за действиями и решениями более опытного ПМа уже не так страшно стать руководителем небольшого проекта. И дальше набивать все шишки самостоятельно, приходя за консультациями к супервайзеру.

Интересно было бы почитать как начинающих ПМов: как вам дается вход в профессию, от кого получаете поддержку, с чем возникают сложности?

Так и уже опытных ПМов: возможно, вы вспомните, как начинали свой путь, про первых клиентов и как вас принимали команды. Может быть, кто-то с теплотой вспомнит своего первого наставника Відкрити / Коментувати

2021-10-27 16:24:18 ​​Фабрика по производству Middle PM-ов. Часть II

Обещанный разбор вчерашней истории с Junior ПМом.

Как так получилось, что команда не знала роли Junior ПМа Варвары, ее функций на проекте?
Скорее всего, просто никто не проговорил участие Варвары и ее зоны ответственности команде, не положил RACI-матрицу на проектную wiki, не ответил на немые или даже задаваемые командой вопросы.
Я не ждала бы, что это сделает сама Варвара. Здесь правильно было бы старшему менеджеру, Тимофею, взять это на себя

Норма ли это, что Junior ПМ присутствует на митингах в теневом режиме? Не фасилитирует их и не активничает?
Мое мнение – да, это . Нужно вникать в особенности проекта, в проблемы, которые обсуждает команда, изучать терминологию.
Чтоб не быть совсем бесполезным на встречах, я бы просила джуниор ПМа писать протоколы встречи (meeting minutes) Так и усвоение материала лучше, и документационный скилл растет, и команда видит некий вклад.

Еще вполне можно было бы отдать Junior ПМу контроль договоренностей со встречи.

Может ли руководить проектом «человек, который не посчитал ни одного эстимейта, не собрал ни одного требования, никогда не общался с заказчиками, не имеет опыта в доменной области, не написал ни одной строчки кода?»
Отдельно прокомментирую часть про «не написал ни одной строчки кода». Если не считать нескольких сверстанных страниц 13 лет назад, то я тоже ни одной строчки кода не написала.

Без этого скилла вполне можно быть толковым ПМом. Мы разбирали с моими коллегами с техническим бэкраундом плюсы и минусы наличия девелоперского прошлого. Если интересно, можно почитать:

https://t.me/pmkotel/52
https://t.me/pmkotel/53
https://t.me/pmkotel/54

Насчет остальных «никогда» – собственно, не может же на человека этот опыт упасть с неба. Нужно дать ему возможность попробовать это сделать

Хорошо, если есть теоретические знания и разобранные примеры по сбору требований и их документации, по составлению WBS и техникам оценки и т.д.

Сомневаюсь, что где-то есть ПМы, заваленные работой по проекту, мечтающие научить всему этому джуниора. Поэтому эти знания все-таки очень правильно получить до того, как устраиваться на работу менеджером проектов. Здесь в помощь желающим различные курсы и интернатуры. Там же и бизнес-коммуникации подтянут

Если эти знания были, да учитывая прекрасный английский Варвары, после нескольких месяцев дообучения на проекте ее вполне можно было бы представить клиенту и звать на отдельные встречи

Так, на следующем проекте у нее уже был бы и опыт общения с заказчиком, и понимание специфики разработки ПО, и опыт работы с различными проектными артефактами.

Проблема ли, что составленная джуниор ПМом диаграмма Ганта не показывала реальные планы и прогресс на проекте?
Я бы сказала, что проблема, если эту диаграмму кто-то показал клиенту. А так вполне можно было дать задание Junior ПМу поупражняться в составлении этой небезызвестной диаграммы и отслеживания по ней прогресса

Я бы еще просила анализировать отклонения, делать выводы и раз в иногда перестраивать план с учетом увиденных ошибок.

Если план показали клиенту, то здесь скорее ошибка Тимофея на проекте – нужно было перепроверить кучу нюансов: учтены ли зависимости, все ли активности включены в план, заложены ли отпуска\болезни\буферы, как аллоцированы ресурсы и т.д.

Завтра мы продолжим
Хочу с вами поделиться советами о том, что можно сделать, чтобы быстрее получить боевой опыт и наломать меньше дров Відкрити / Коментувати

2021-10-26 17:43:25 ​​ Фабрика по производству Middle PM-ов. Часть I
Карьерный путь технических специалистов в IT понятен: Junior-Middle-Senior – дальше кто там что выдумал в компании: архитектор, principal, техлид, самый-главный-на-районе тестировщик/разработчик/DevOps
Логично, что менеджеры тоже должны пройти этот путь, правда
А вот и не совсем.
️Почему-то клиенты не хотят видеть приставку “Junior” рядом с позицией ПМа, которому они доверяют свой проект. И команда не всегда будет рада начинающему специалисту у руля, понимая, что недостаток опыта и квалификации могут им дорого стоить: конфликты, непредвиденные риски, сверхурочная работа и т.д.
Хочу поделиться историей от моего друга, iOS техлида в одной из компаний Харькова. Назовем его Аврелием. Имена участников истории тоже заменим для пущей анонимизации.
“Одна из вещей, которая меня поразила: оказывается бывают Junior ПМы!
Я работал на проекте, и у нас был ПМ Тимофей. В то же время у нас была ПМ Варвара.
Меня слегка удивило, что у нас два ПМа, но у нас было разделение на два подпроекта, поэтому вроде бы какая-то логика была
Варвара начинала ежедневный стенд-ап, все рассказывали свои статусы, а потом Варвара желала всем приятного дня. Остальные митинги она даже не начинала, но непременно присутствовала и молчала.
Груминги и плэнинги вела БА, рабочие вопросы девелоперы проясняли с дизайнером и QA.
Я долго задавался вопросом: что же она делает на проекте?
Позже я узнал, что Варвара — преподаватель английского языка, которая решила войти в АйТи. И Junior ПМ.
Мой мир содрогнулся. Руководит проектом человек, который не посчитал ни одного эстимейта, не собрал ни одного требования, никогда не общался с заказчиками, не имеет опыта в доменной области и не написал ни одной строчки кода?
Она научилась составлять диаграмму Ганта, но никто не работал как она предполагала.
Кастомер кричал, что мы срываем сроки , а наш шеф решил порвать с ним контракт из-за его токсичного поведения и угнетения команды.
Говорить с клиентом было крайне сложно – найти общий язык не удалось даже Senior ПМу. А Junior ПМ Варвара так с заказчиком и не пообщалась. Это был ее первый и последний проект в нашей компании. Вроде бы сейчас она ПМ в большой и известной компании”.
Я эту историю читала почти как остросюжетный триллер

Давайте завтра разберем некоторые допущенные Варварой и Тимофеем ошибки, и как же все же начинать путь ПМа, чтоб это было наименее травматично как для самого специалиста, так и для его окружения Відкрити / Коментувати

2021-10-22 12:12:25 ​​ Без меня меня женили. Или почему давать клиенту сроки без оценки команды – плохо.

«И чтобы до конца дня были натерты полы, помыта посуда, наколоты дрова на месяц и высажены сорок розовых кустов!»
Вы же наверняка помните этот монолог злой мачехи из сказки «Золушка»? Так вот, примерно такой же «злой мачехой» ПМ выглядит для своей команды, когда договаривается с клиентом о сроках без оценки работ от специалистов

«Сам наобещал, пусть сам теперь и выполняет», думает команда, и эта реакция вполне оправдана. А если между ПМом и командой ко всему прочему еще и конфликт, то ребята вполне могут саботировать такой релиз, даже если изначально в озвученные сроки попасть было реально. Чтобы впредь неповадно было так поступать.

И я здесь всецело на стороне команды. Не надо так. Нет у ПМов достаточно экспертизы, чтоб самостоятельно оценить все работы и в полной мере нести ответственность за попадание в сроки/бюджет на основании таких оценок.

Почему ПМы иногда оказываются в таких ситуациях и как этого не допустить?

Клиент «спустил сверху» сроки, в них нужно попадать.
Опасно: ПМ подтверждает, что все будет сделано в эти сроки, не дождавшись оценок команды.
Лучше: подтвердить, что ограничение по срокам принято во внимание. Пообещать вернуться к клиенту с информацией, какая часть работ может быть выполнена в эти сроки после оценки командой.

Клиент потребовал информацию о сроках или стоимости asap, не было возможности организовать полноценную оценку всей командой.
Опасно: ПМ самостоятельно сделал какие-то прикидки по аналогии с прошлыми релизами, заложил буферы и установил дедлайн.
Лучше: рассказать команде о срочной задаче на оценку, привлечь хотя бы нескольких представителей команды к оценке работы, добавить буферы, разделить с командой ответственность за сделанную наспех оценку. Клиенту прокоммуницировать точность такой оценки и риски, предложить уточнить оценку и сроки уже без спешки.

ПМ не хочет отвлекать команду от срочного релиза, считает, что есть достаточно данных для более-менее точной оценки.
Опасно: дать оценку самостоятельно, ни с кем ее не подтвердив.
Лучше: дать лидам провалидировать артефакты (оценку, диаграмму Ганта и т.д.). Договориться сделать проверку в овертайм, если иначе страдает ваш срочный релиз.
Или обсудить с клиентом возможность отложить планирование следующего релиза до окончания работ по текущему, объяснив ему последствия отвлечения команды на оценку.

Варианты «лучше» не гарантируют менеджеру точность оценки. Но хотя бы дают понимание команде, что их мнение важно, без их согласия их не «женят»
И если таки придется успевать в оценки и сроки, выданные наспех, то коммитмент команды будет гораздо выше. Відкрити / Коментувати

2021-10-19 14:14:36 В предвкушении осеннего Open Tech Week
В этот раз заявлена всего одна тема, на которую будут дискутировать участники: «Вопросы к ПМам от не ПМов или все, что вы хотели узнать про работу ПМа и боялись спросить».

Когда я увидела, кто модератор, сразу взяла билет.
Зная Алексея, здесь будет много юмора, провокаций, глубоких мыслей и снова немножко юмора.

Спикеры митапа:
Алексей Могильный, Program Manager в Sigma Software
Денис Прилуцкий, PMO Director SoftServe
Модератор: Алексей Сиротюк, Innovations Department Manager в Sigma Software.

Регистрация здесь. Відкрити / Коментувати

2021-10-15 16:25:48 ​​#менеджменткакискусство

Как техлид описывает код продукта, который нам достался от других разработчиков.

Джексон Поллок, «Конвергенция», 1952 Відкрити / Коментувати

2021-10-12 17:40:09 ​​ Машина, которая не любит ванильное мороженое. Или почему важно делать анализ корневых причин.
Перескажу вам историю, которую, если не ошибаюсь, очень давно вычитала в книге Ли Якокка "Карьера менеджера". Увлекательная, кстати, книга, которую смело могу рекомендовать

Штаты, 60-ые годы.
Официальному дилеру Ford пришла жалоба примерно следующего толка: «Моя машина ненавидит ванильное мороженое из Baskin Robins. Каждый раз, когда я его покупаю – она не заводится. Если мороженое другого сорта, например, клубничное или шоколадное – нет проблем, машина на ходу! ».

Машина была на гарантии. Дилер присылает по запросу специалиста.

Отправляются за мороженым . Приезжают в магазин, хозяйка машины идет за ванильным мороженым – все верно, машина не заводится! Несколько раз они экспериментировали: клубничное – заводится, шоколадное – заводится, ванильное – нет.

Механик был реалистом, и не мог поверить в ненависть машины к сорту мороженого. Он продолжал ездить в Baskin Robins и отмечал все детали поездки: время, скорость, температуру В результате, было выявлено следующее: ванильное мороженое, как самое популярное у сладкоежек, находилось у входа в магазин и уже было расфасовано. Все остальные - в самом конце зала, его нужно было попросить взвесить и запаковать. Купить ванильное мороженое можно было значительно быстрее, чем остальные сорта. Теперь нужно было понять, почему машина не заводится, если вернуться к ней быстро. Ответ нашли: двигатель не успевал остыть, в карбюраторе оставались пробки, вызванные испарением бензина
Техническую неисправность устранили, когда докопались до глубинных причин.

Из сферы автосервиса в сферу айти. Если зафиксировать только симптом и пытаться вылечить его, то жди повторений проблемы
Чтоб найти и проанализировать корневые причины есть отдельный процесс из шести этапов - Root Cause Analysis и ряд вспомогательных техник: 5Whys, диаграммы Ишикавы, Парето…

Примеры недостаточно глубокого анализа и поверхностных выводов:
Мы не вложились в график, потому что у нас заболел разработчик.
Приложение не выдержало нагрузку в 1000 пользователей, т.к. мы не провели нагрузочное тестирование.
Произошла утечка данных из системы из-за дефекта в сторонней библиотеке, которую мы подключали.

Со стороны такие объяснения звучат достаточно близко к "моя машина не заводится, когда я беру ванильное мороженое в Baskin Robins"
Планирую посты про анализ корневых причин и некоторые техники. Если хотите разбор своей проблемы, то можно ее описать в комментариях Відкрити / Коментувати

2021-10-08 16:23:00 Если вы решили провести этот пятничный вечер дома, то можно скрасить его просмотром докладов с Open Tech Week – серии благотворительных митапов от Sigma Software. А можно сохранить этот пост в Избранное и посмотреть при удобном случае

Рекомендую к просмотру три доклада, которые получили отличные отзывы от аудитории и будут полезны даже опытным ПМам.

«Эффект бабочки»
Спикер: Олеся Хохуля, Tech consultant

Как маленькие детали в построении коммуникации с клиентом и командой могут полностью менять судьбу проекта, как в положительную, так и в отрицательную сторону? На какие важные моменты стоит обращать внимание для успешной реализации проекта?

«Как закрывать проекты»
Спикер: Алексей Сиротюк, Innovation Department Manager at Sigma Software

Алексей дал комичную авторскую классификацию проектов, подходящих к концу, и поделился забавными историями из жизни.
Из доклада можно узнать, в чем польза для ПМа от правильно закрытого проекта и получить исчерпывающий чек-лист обязательных для ПМа активностей перед завершением, чтоб избежать ошибок, о которых рассказывает автор.

«Good contract vs. Customer Expectations. What will safe you if the storm strikes»
Спикер: Анна Бойко, Account Manager в Sigma Software

Тема говорит сама за себя Этот доклад точно пригодится тем, кто в дальнейшем планирует работать в плоскости построения и укрепления сотрудничества с клиентами. Из доклада вы узнаете:
про модели сотрудничества с клиентом и как выбрать подходящую для конкретного проекта,
игра в испорченный телефон: как быть, если продали не то, что изначально нужно было клиенту,
как сделать так, чтобы ожидания клиента оставались правильными во время длинного пути реализации проекта.

Прекрасной пятницы и приятного просмотра Відкрити / Коментувати