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

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

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

Предупреждаю, что путешествие в глубины будет долгим, так что налейте чаю и подготовьтесь морально. Учтите, что я не несу юридическую ответственность за ваше следующее нападение на заказчика или последующее увольнение. Если готовы, начинаем спуск.

«Всё, договорились, скрам-мастером теперь будет Полина», — отлично, кто-то договорился о том, что я буду скрам-мастером. Отрицание, гнев, торг, депрессия, принятие.  

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

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

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

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