Управление проектами *

В данной статье материал был собран летом 2020 года, отчасти информация устарела. Но хотелось бы поделиться собранным опытом. Автор текста: Анатолий Ерофеев.

Привет, Хабр! Меня зовут Екатерина Герт. Вот уже больше 10 лет я работаю системным аналитиком в проектах по заказной разработке ПО для компаний из разных отраслей и госсектора. Это всегда работа над большими проектами. 

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

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

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

Поехали! 

Тимлидами редко рождаются, чаще — становятся. Самый частый пример, который я видел — тимлидом назначают самого ответственного разработчика из команды. Наделить ответственного человека еще большей ответственностью — сильное и эффективное решение, правда же? 

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

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

Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание рамок (от англ. "scope creep", также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.

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

Что такое Process Mining и как его применять, мы рассказывали в первом посте. Во второй части мы представили краткое руководство пользования библиотекой для интеллектуального анализа процессов SberPM. В данной статье мы подробнее раскроем функционал библиотеки и расскажем о новом модуле оптимизации процессов и клиентских путей, использующем обучение с подкреплением для поиска оптимального пути.  

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

·         Отсутствие зацикленности.

·         Минимальное время выполнения этапов.

·         Минимальное число этапов.

·         Успешное завершение процесса.

Технический долг — особый вид долга: мы занимаем у самих себя, причем нередко с большими процентами. Несмотря на то, что платить по счетам рано или поздно приходится, устранение техдолга редко относится к насущным бизнес-задачам. Бизнес либо откладывает это «на потом», либо вообще не рассматривает как проблему.

Я думаю, главная причина непонимания — в том как мы, инженеры и разработчики, пытаемся объяснять бизнесу, почему важно избавляться от техдолга. Мы транслируем наше видение из нашего технического мира, забывая, что у бизнеса другие критерии оценки важности проблем. Мой доклад, с которым я выступил на DevOpsConf 2021, как раз о том, как устранить это непонимание и «продать» бизнесу технический долг.

Оказалось, качество звука — это не первое, на что операторы кол-центров обращают внимание. В смысле, что, конечно, оно отличается от устройства к устройству, но всё равно во многом зависит от линии, стабильности соединения и устройства абонента, а не от того, что на принимающей стороне. 

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

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

Решает эргономика. И операторы выбирают то, что не сплющивает голову к вечеру. 

Я Android-разработчик и хотел бы сам решать, какие задачи мне делать, а какие нет. У вас бывало такое желание? Можно ли так делать на работе? Мой краткий и возможно, интригующий ответ — можно. Ключ к этому — погружение в бизнес.

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

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

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

Существует множество мифов и заблуждений, связанных с инженерией требований и Agile. В этом разделе мы поговорим о распространенных мифах, которые, вы, возможно, ежедневно слышите в своих командах и компаниях. Давайте же рассмотрим их.

Миф 1: В Agile-среде не может быть авансов

Часто даже в зрелых продуктовых командах есть миф о том, что если вы хотите следовать Agile, то стоит забыть о любых предварительных активностях. Для реального мира Agile – это ошибочное суждение. Вам необходимо пройти несколько подготовительных этапов (например, разработать концепцию продукта), чтобы создать компас, который будет задавать курс разработке. Помимо написания кода и тестирования, вы можете формировать и использовать инженерию требований в Agile-итерациях.

Миф 2: Инженерия требований – это бумажная работа

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

Обычная практика при работе с госами - это долгосрочное планирование, тщательное проектирование, разработка по детальным спецификациям, тестирование и релиз раз в три-четыре месяца. Вроде все логично и понятно но, по моему опыту, в современном быстро меняющемся мире работает далеко не идеально. Многие технологические компании (Amazon, Facebook, Netflix и др.) уже отказались от такого каскадного подхода: формируют гипотезы, проводят  множество маленьких экспериментов для их быстрой апробации в бою. Думаете, чтобы разработать ракету нужен детальный техпроект, план и далее сборка по чертежам? Тогда вы сильно удивитесь, если прочитаете, как это делается в SpaceX.  С таким же недоумением со стороны коллег я сталкиваюсь, когда говорю, что мои команды на госпроектах делают каждый день релизы, организуют частые показы заказчику или пользователям. А еще мы не пишем детальных спецификаций и постоянно развиваем инженерные практики. Почему такой подход имеет место быть и приводит к хорошим результатам, расскажу на примере проекта по созданию ГИС Открытый контроль. 

Как же вы планируете без диаграмм Ганта? Почему ваши разработчики не оценивают задачи? Зачем вы делаете частые релизы и частые показы? Что делаете, еcли прилетела срочная задача от заказчика? Какие инженерные практики вам пришлось внедрить, чтобы делать релизы каждый день? Ответы на эти вопросы, а также то, почему мы отказались от Scrum вы найдете в статье.

Основано на реальных событиях.

 - Виктор, добрый день, очень рад вас видеть! Прошу, проходите, присаживайтесь! – искренне улыбаясь, жму руку потенциальному спасителю нашей компании.

Я давно интересуюсь скрамом, был опыт его применения, но вживую настоящего скрам-мастера я никогда не видел. Разве что на паре конференций, где удавалось посмотреть феерические выступления истинных мастеров этого ремесла. И вот, откуда не возьмись, в наших провинциях возник Виктор, дипломированный скрам-мастер. Более того, он сам прислал нам резюме. Не на конкретную должность, как соискатель, а для обсуждения возможного сотрудничества, как потенциальный партнер.

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

 - Да, добрый день, друзья. – начинает Виктор. – Меня зовут Виктор, я принёс вас настоящий скрам. Предлагаю обсудить варианты сотрудничества.

Повисла неловкая пауза. С одной стороны, у меня в голове был целый ворох вопросов по методике и практике применения скрама, но они вряд ли подходили для собеседования. С другой стороны, я примерно представлял, кто такой скрам-мастер и чем он занимается, поэтому не знал, что спросить на тему «а чем вы у нас будете заниматься?». Но выручил Александр.

 - Итак, скрам... – Александр сложил ладони вместе, медленно опустил их на стол, выдержал паузу («завис»), будто обдумывая следующую фразу. – Иван заставил меня изучить, что это за методика, в рамках подготовки к этой встрече. Я сразу честно скажу – прочитал лишь половину книги. Поэтому, Виктор, если не затруднит, можете в двух словах рассказать, что именно хотите нам предложить? Чем будете заниматься, проще говоря?

Когда задачи не выполняются, виноват часто не только тот, кто их делал, но и тот, кто ставил. Ведь от правильной постановки напрямую зависит качество и эффективность выполнения. Не приложили инструкций, не объяснили целей и ожидаемых результатов, не дали инструментов – вот у сотрудника или подрядчика и не получилось сделать все, как нужно.

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

С тех пор как удаленка стала массовой, количество статей на тему онбординга множится в геометрической прогрессии - сотрудников-то на проекты нанимать надо. Но среди десятков советов, как именно вводить новичка в курс дела, мы не видим главного - “начать с Консерватории”, т.е. выстроить внутренние рабочие процессы в компании и убедиться, что они функционируют в какой-то среднесрочной перспективе. После этого добавление “онбординга”, как отдельного процесса, пройдет легко и безболезненно. А главное, этот онбординг заработает! 

Мы уже 5 лет на удаленке. Сегодня расскажем о том, как выстроен наш онбординг и что у него на “подтанцовке”.

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

Как это проходит. Лучшим сотрудникам (по годовым показателям) приходит письмо на почту с предложением участия в обучении. Сотрудник, на свое усмотрение выбирает то обучение, которое ему больше всего нравится. Иногда, если выбора нет, сотрудника просто оповещают, что такого-то числа он будет проходить обучение по такой-то теме.

В 90% случаев это делается пальцем в небо. Кроме того, что потребность в обучении определяется, не исходя из бизнес потребности, так еще часто сотрудника отправляют по два-три раза на одно и тоже обучение. Лично я уже дважды проходил обучение по ораторскому искусству, которые были на 95% идентичны (ничего нового не узнал, в следующий раз смогу сам проводить такое обучение...). 

Вся эта система придумана отделом кадров для мотивации сотрудников. С каких пор обучение чему-попало стало мотивацией, понять я не могу… . Дайте лучше коллегам премию или купите подарок. Нафига отправлять на ненужное обучение?! Ну да ладно, пусть будет так, мне не жалко (деньги то не мои). Я, в целом, не против, чтобы сотрудник развеялся. Но, мне не нравится следующее… . Подобное обучение часто проходит в конкретно заранее спланированные дни и уже второй год подряд ряд моих сотрудников отправляют вместе на двухдневный семинар в самый пик сезона. Из-за этого, мне и всем остальным сотрудникам приходится работать до 10 вечера, мы не успеваем и весь отдел теряет премию (а компания, прибыль)… .” - имя автора и компания скрыты.

Листая страницы Хабра, поймал себя на мысли, что я воспринимаю Хабр  как новостную ленту в социальной сети. То есть как нечто, что прямого отношения лично ко мне не имеет и касается меня очень  косвенным путем. Нечто полуразвлекательное-полупознавательное.

Ну, судите сами. Вот примерный список тем, которые превалируют на Хабре.

1. Что там новенького  у Илона Петровича Маска.

2. Как с помощью Arduino, говна и палок сделать годный фаллоимитатор радиоприемник.

3. Как я ушел с прошлой работы, и как мне было там плохо.

4. Как я нашел свою текущую работу, и какая она крутая.

5. Как живется специалисту X в стране Y.

6. Какой путь нужно проделать фельдшеру из Ангарска, чтобы стать тестировщиком мобильных приложений в Ирландии.

7. Обсуждение новомодной платформы для веб-разработки, которая через 3 года станет старомодной.

8. Промываем косточки крупным компаниям.

9. Исторические экскурсы в IT/технологии/медицину.

10.   Реклама компаний.

11.   Мнения обо всем отвлеченном на свете.

12.   И т.д.

Все эти темы и все статьи – неплохие, интересные. Но я хотел бы другого.

Нас вы, скорее всего, знаете по блефарогелю для глаз и ещё разной косметике и медсредствам. Но если брать основной выход нашего производства по объёму, то это гели для УЗИ. В пандемию они стали критичными для страны, потому что с помощью УЗИ нельзя было ни поставить, ни исключить диагноз, но можно было определить, стоит ли вести пациента на КТ. А когда случился коллапс на КТ, УЗИ в кабинетах врачей и региональных клиниках очень помогали. 

А ещё в пандемию случился дефицит контейнеров, спиртовой коллапс, аптечный кризис, косметологический кризис, приезды «гостей с юга» с чемоданами денег за компонентами производства, постоянное обнуление пропусков наших критичных сотрудников производства ДИТом из-за багов и море других вещей. Всё это на нас, конечно же, отразилось. 

Теперь, когда мы все будем вспоминать 2020 год как первый год с возрастным рейтингом, я могу рассказать эти тёплые ламповые истории. 

Зачем нужна Большая ретроспектива на несколько команд и как ее провести

Привет. Я Лена, скрам-мастер в «Ренессанс страхование». Мы с коллегами в командах реализуем классные фичи в страховании и рады, когда наш функционал действительно получается востребован. Стараемся еще, конечно, чтобы получался он не только качественно, но и быстро, как это обычно требуется в современном мире.

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

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

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

«Я как-то видел, когда в команду разработки закинули задачу распилить монолит. И всё. Люди должны были работать в два раза больше – это ужасно».