Краткое резюме: проект на грани провала. Всем кажется, что он не уложится в сжатые сроки. Но приложение было выпущено вовремя и без ошибок. Как такое возможно?

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

Проект

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

Какие стороны были вовлечены:

  • Владелец продукта (ЗП)
  • Front-end команда (2 разработчика)
  • Бэкэнд-команда (2 разработчика)
  • Команда QA (2 тестировщика)
  • UX / Дизайнер
  • Контент-менеджер (переводы)

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

Контекст проекта

Быстрорастущие компании обычно инвестируют в новых сотрудников и изменения в иерархической структуре. Из всех 9 задействованных сотрудников 2 были новыми сотрудниками (заказчик и дизайнер), 2 имели год опыта в организации и из все 6 команд 3 были заново сформированы, а остальные были реструктурированы в определенной степени. Недавно сформированная команда UX была сосредоточена на пользовательских интерфейсах в Figma, а переводы выполнял контент-менеджер, который поменял отделы. Кроме того, создание приложений с помощью заказа на поставку было для нас в новинку - раньше эти обязанности выполнял менеджер проекта.

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

Так много нового, нового, нового.

Подводя итог:

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

Цель проекта

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

Чтобы усложнить ситуацию, проект должен учитывать все сервисы, дополнительные продукты и пользовательские пограничные случаи, которые были затянуты за годы разработки продукта.

Что скомпрометировало проект (первые признаки)

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

Небольшое примечание. Часто провал проекта определяется несколькими общими факторами. В одном из своих недавних информационных бюллетеней (Мысли об ошибках) Николас Закас сгруппировал их так: навыки, удача и скрытая информация . В такой комбинации они влияют на результат решения, но все они применимы к ИТ-проектам в целом.

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

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

На что подсказала скрытая информация:

  1. Нет четкого руководства.

Отсутствие специального менеджера проекта или полностью доступного руководителя проекта приводило к постоянным отвлечениям для выполнения организационной деятельности.

2. Недостаток знаний в предметной области.

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

3. Неполные требования.

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

4. Слишком много команд.

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

Все эти последствия, конечно, не оставили нас, но вынудили (по крайней мере, интерфейсных разработчиков) сознательно обратиться к проблемным областям как с точки зрения кода, так и с точки зрения управления.

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

Ответственные за разработку

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

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

Цитата из когда следует использовать XP хорошо описывает ситуацию, в которой я находился в тот момент. Наше техническое сообщество взяло на себя инициативу, потому что: мы знали, что QA и backend-разработчики хорошо разбираются в предметной области, наша команда front-end может обеспечить быструю обратную связь, мы ближе к пользовательскому интерфейсу и достаточно гибки, чтобы допускать поздние изменения .

Это был правильный шаг. Подобные ситуации следует рассматривать как чрезвычайные и по возможности избегать. Нет ничего лучше, чем работать в постоянной фазе, делать то, что у вас получается лучше всего, в то время как PM занимается межкомандными связями. Все расселись по своим местам, и больших сюрпризов ждать не приходится. Говоря это, я также понимаю, что это в основном принятие желаемого за действительное. Суровая правда заключается в том, что большинство компаний не являются гибкими, не следуют какой-либо структурированной методологии и не применяют такие структуры, как SCRUM или Kanban. Я фанат Канбана, но даже его очевидных преимуществ редко бывает достаточно, чтобы убедить организации попробовать его сейчас. Несмотря на бесконечные пустые разговоры и большие инвестиции в гибкие платформы, такие как SCRUM fx., большинство компаний полагаются на XP, даже если они этого не осознают. Обязанности разработчиков совпадают с PM, маркетингом, SEO, дизайном и т. Д., И это не случайно.

Стратегия разработчиков по устранению препятствий

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

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

Еще раз четыре препятствия:

  1. Нет четкого руководства.
  2. Отсутствие знания предметной области.
  3. Неполные требования.
  4. Слишком много команд.

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

Давайте посмотрим поближе.

Нет четкого лидерства

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

  • Требования к проекту
  • Обязанности между командами
  • Front-end задачи
  • Репо проекта и кодовая база
  • Каналы связи
  • Разделение и оценка

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

Отсутствие знаний о предметной области

Стало очевидно, что QA и бэкэнд-команды лучше всего понимают большинство основных сценариев использования. В этой ситуации помогли два действия:

  • Быстрые короткие итерации и ранние выпуски.

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

  • Частые встречи по синхронизации.

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

Неполные требования

Неполные требования часто «облекаются» в «окончательный» дизайн пользовательского интерфейса и обычно фиксируются поздно, когда QA берется за интерфейсный прототип. Для ответа был использован следующий рецепт:

  • Развертывайте неполные прототипы.

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

Принцип DRY бесполезен при работе с часто изменяющимися предпосылками, где WET codebase позволяет быстро вмешиваться без побочных эффектов.

  • Сопровождайте каждое изменение рефакторингом.

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

  • Тщательно проверьте это.

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

Слишком много команд

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

Каким образом фронтенд-команда компенсировала затраты на координацию:

  • Передача обязанностей между собой.

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

  • Установите прямые каналы связи.

Это было сделано в Slack для всего, от обновления статуса до обсуждения требований и планирования встреч.

Сводка передовых практик

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

Проведите вводную встречу: укрепляет уверенность в себе и снижает стресс.

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

Делайте итерации короткими. Быстрая обратная связь и идеи для тестирования.

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

Используйте принцип WET vs DRY: безболезненные и частые изменения с незначительными побочными эффектами.

Внесение изменений в сочетании с рефакторингом: высокое качество кодовой базы и более быстрое внесение изменений в будущем.

Проверьте крайние случаи. Минимизирует нестабильность кода с течением времени. Высокие шансы выпустить продукты без ошибок.

Обязанности по совместному управлению: уменьшает многозадачность и позволяет сосредоточиться на технологических задачах.

Заключительные слова

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

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

То, что случилось, приходит, чтобы подтвердить

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

Запомните это небольшое руководство, если ваш следующий проект окажется под угрозой.

📩

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

Ресурсы

Первоначально опубликовано на https://webup.org.