Я разработчик среднего уровня в небольшой компании, состоящей примерно из 15 человек, и я (стремлюсь) руководить командой из 3 человек. Я обеспокоен тем, что моя команда по понятным причинам страдает от постепенной потери инвестиций в проект и компанию в целом. Наша компания не может создать дружественную среду для разработчиков, отчасти из-за проблем с человеческими ресурсами, но, на мой взгляд, в основном из-за проблем с управлением проектами. Честно говоря, я остаюсь, потому что мне нравятся сложные задачи, когда дело доходит до починки того, что сломано. В последнее время также произошли некоторые изменения в мышлении уровня C, которые вселяют в меня оптимизм в отношении предложения изменений.
Говоря здесь только о нашей команде из 3 человек, мы несем ответственность за поддержку кодовой базы из чуть более 150 000 строк кода, представляющих в основном серверную часть одного продукта с вспомогательными службами. В качестве примера нашего технического долга более половины этого кода написано на устаревшей языковой версии (Python 2.7), а задачи по переходу на более новые версии были запланированы более чем на год и распределены на более чем 6 месяцев; нам еще не удалось успешно его протолкнуть. Наш последний спринт был наполовину заполнен исправлениями ошибок, что не является чем-то необычным. Наш код часто дает сбой, и многие из этих сбоев даже не достигают бэклога. Я внедрил модульное тестирование, но наше покрытие низкое и не улучшается. У нас есть систематические проверки, но они не позволяют эффективно находить дефекты. Нас подталкивают выпускать раньше и часто, но для синхронного выпуска может потребоваться синхронизация с другими командами, и уже одно это вызвало много проблем и дискуссий. Тестирование занимает несколько минут, и наш бот непрерывной интеграции отвечает в течение 2 часов, а результаты иногда подлежат интерпретации.
Мы используем терминологию Scrum, хотя и не внедряем Scrum полностью. У нас есть ритуалы, но с организацией работы берется много свободы — от срочных сбоев, возникающих в спринте, задач, указанных в середине спринта, отсутствия Scrum-мастера и многого другого. Разработчики сообщили, что технический директор навязывает им технические предпочтения, несмотря на их возражения по поводу их оптимальности.
Предыдущий руководитель попросил поменяться командой, кто-то, работающий в филиале нашей команды, находится на больничном (и я знаю, что это связано с работой), кто-то ушел раньше, а кто-то планирует уйти в январе. Все это произошло только в нашей команде за 2 года.
Этому катастрофическому сценарию есть контекстуальное объяснение, история компании, специфика нашего продукта, отсутствие опыта у наших менеджеров в управлении программными проектами, а также отказ от инвестиций и злоба самих разработчиков; но меня больше интересуют решения, чем анализ, следуя оси 1. удержания разработчиков и 2. вывода ценности разработки:
Если люди, заставляющие разработчиков уходить или работать неэффективно, не находятся под вашим контролем и не слушают вас, вы мало что можете сделать. Призывать разработчиков оставаться вопреки их собственным интересам не получится.
Вы не можете исправить плохое управление снизу.
В нынешнем виде вопрос действительно широк, поскольку вы охватываете несколько различных аспектов, таких как « как справиться с техническим долгом », « как обрабатывать ошибки в середине спринта , а также здесь », « как мотивировать разработчиков в такой среде ».
Нет волшебной пули . Как напоминает Корнелиус Фихтнер в своем PrepCast , мы должны есть слона по кусочку за раз.
Существует так много вопросов, связанных с мотивацией (ваш пункт № 1), что для этого есть специальный тег, и очень сложно что-то выделить. В любом случае стоит узнать больше о том, как работает внутренняя мотивация .
Для предоставления ценности (ваш пункт № 2) вам нужно будет использовать общий язык между C-level и командой разработчиков. 4 ключевых показателя предлагают простой, но мощный набор аспектов для измерения, понимания, где вы находитесь и куда хотите двигаться.
Кроме того, в такой сложной (и потенциально разочаровывающей) среде я бы посоветовал уделить некоторое внимание не только наблюдению за тем, где вы находитесь сейчас, но и на тенденциях с течением времени . Сегодня у вас может быть 5% покрытия тестами, и это может быть очень неприятно... но вы должны думать, что в прошлом месяце у вас было 2%. Тенденция (и самое главное, положительная тенденция) — настоящий мотиватор. При разговоре с командой разработчиков вы можете показать восходящий тренд, а не необработанные цифры.
В любом случае, установление ожиданий является ключевым моментом — все должны знать, что команде потребуется сделать один шаг назад (т. е. уменьшить или вообще не выполнять бизнес-план в течение некоторого времени), чтобы иметь возможность сделать несколько шагов вперед в будущем.
Каковы хорошие измерения того, где мы находимся и насколько мы улучшаемся?
С точки зрения Канбана я бы предложил время выполнения заказа, а с точки зрения Scrum я бы предложил скорость/производительность. Время выполнения — это количество времени, которое требуется для того, чтобы часть работы прошла путь от «только что начал работать над ней» до «готов к запуску». Скорость — это то, сколько работы вы можете выполнить за определенный период времени. На самом деле это просто два разных способа визуализации одного и того же. Тем не менее, может быть полезно иметь отдельные измерения для обоих, в зависимости от вкуса вашего руководства. YMMV.
Каковы хорошие указатели с точки зрения управления проектами для подобной ситуации? Я не ищу готового решения, такого как Scrum, а скорее руководств и небольших постепенных изменений в организации, которые могут привести к улучшению.
Задача рамы: вам следует искать решение для полки... пока.
Проверьте менталитет Шу Ха Ри . Первый шаг, Шу, это то, где вы точно следуете руководству/процессу/коучу . Вам не нужно беспокоиться о понимании « почему» на этом этапе — вам просто нужно заботиться о том, что , кто , когда и как .
Второй этап, Ха, наступает только после того, как вы освоите процесс, описанный в книге . Как только вы полностью освоите механику процесса, вы начнете спрашивать «почему» и начнете пробовать другие, связанные процессы (например, ScrumBan), начнете настраивать переменные части вашего определенного процесса (например, продолжительность спринта).
Затем, наконец, стадия Ри — это когда вы освоили что, кто, когда, как и почему. На этом этапе вы можете начать вносить любые изменения, которые считаете необходимыми, исходя из своего понимания.
Попытка прыгнуть прямо на стадию Ри - вот как вы это получите .
При этом, если вам нужно, не стесняйтесь начинать с постепенных изменений, а не с оптовых — просто убедитесь, что все эти постепенные изменения идут в точном соответствии с документом, потому что вы все еще находитесь на стадии Шу. все время. Не беспокойтесь о попытках улучшить Scrum, пока вы впервые не попробуете Scrum в полной мере. Будь то одна встреча с руководством с месяцем испытаний как есть или пять лет постепенных изменений.
Что ж, как опытный эксперт по программированию , я бы добавил, что вполне возможно, что вы еще не осознаете истинную природу технических проблем, с которыми могут столкнуться ваши команды.
Ваша текущая языковая версия действительно может быть более или менее несовместима (!) с «версией того же языка», на котором изначально была написана эта система. Да, " фундамент тоже движется".
Усугубляет ситуацию тот факт, что каждое приложение по своей сути опирается на «сторонние библиотеки», которые не разрабатывались вашей командой, но которые также обязаны заново адаптироваться к постоянно меняющейся цели.
Около полутора лет назад мне пришлось провести команду через неприятный опыт реинжиниринга очень старой (sic...) системы на основе «OsCommerce» с PHP-5 на PHP-7, буквально для того, чтобы дать компании достаточно времени, чтобы вывести его из эксплуатации. В результате мы изменили около 40% всего исходного кода в этой системе... просто чтобы сохранить его там, где он был. (И нам пришлось переработать большую часть логики , чтобы обойти то, что какой-то дизайнер языка где-то решил, что оно теперь «устарело» или полностью удалено из языка.
Системная архитектура Python более снисходительна, но уродливые принципы остаются: «Ваша система не единственная в игре».
Я уверен, вы знаете, что на эти темы написаны целые книги! Я читал и представлял исследовательскую литературу по командной работе в течение многих лет и считаю, что она дает вам четкие ответы: дайте команде возможность работать самостоятельно и сосредоточьтесь больше на принципах (таких как Agile Manifesto), чем на процессе. Опытным путем было показано, что они повышают удовлетворенность работой, уменьшают намерение уйти и улучшают измеримую производительность в долгосрочной перспективе. Мой подход здесь (бесплатно и с открытым исходным кодом): Self-Directed Agile .
Однако, поскольку похоже, что вы уже какое-то время используете Scrum, первые шаги могут заключаться в том, чтобы позволить команде скорректировать процесс, чтобы он лучше соответствовал ее потребностям. В каждом Ретро спросите команду, хочет ли она изменить какую-то часть того, как она планирует, отслеживает и выполняет свою работу. Затем позвольте ему вносить изменения по одному. На следующем Ретро обсудите, как все прошло и как повлияло на производительность (хорошее и/или плохое). Затем сохраните, пересмотрите или отмените это изменение и примите решение о следующем. Хотя в этом разделе моего сайта используется некоторый язык, характерный для моего подхода к аджилити, принципы основаны на исследованиях в области психологии и, следовательно, должны применяться к любому другому подходу: Настройка FuSca .
Вы не можете, потому что ваша компания находится в смертельной спирали.
У него принципиально сломанный процесс разработки и устаревшая кодовая база, которую необходимо выбросить и переписать с нуля. Это потребует значительного времени, времени, которое не будет приносить доход, а в такой маленькой компании, как ваша, такое длительное отсутствие дохода приведет к ее закрытию. Что бы ни говорило руководство, чтобы вы остались довольны, вероятность того, что они предпримут действия, которые начисто убьют компанию, равна нулю.
Следовательно, необходимое время никогда не будет потрачено, и ситуация будет только ухудшаться, пока не достигнет точки, когда все старшие разработчики, которые понимают платформу, ушли от разочарования, и остались только младшие, которые не понимают. у них есть опыт, чтобы понять, в какой неразберихе они оказались. А младшие вряд ли создадут хороший код, особенно без помощи старших, поэтому проблема будет только расти.
Извините, но это просто невозможно исправить, сколько бы тестов вы ни добавили. Берите пример с разработчиков, которые уже разобрались с этим и ушли — сократите свои потери и найдите более вменяемое место для работы. Это не вызов, который вы можете преодолеть.
Саров
Дэвид Эспина