Человекоцентричный подход

TL;DR

  • 👑 Доставка королева.
  • 🔭 Визуализируйте и определяйте успех на ранней стадии.
  • 🤹 Не забудьте включить мониторинг производительности и анализ KPI.
  • 🎯 Главный инженер – это руководящая роль. Подумайте о своем участии в проекте.

Для меня работа в качестве главного инженера-программиста — это сближение инженеров, бизнеса и людей.

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

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

Это правильный проект?

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

  • Делать или не делать?
  • Если «делать», то правильное ли это время?
  • Какова инженерная сложность?
  • Как усилия?
  • Есть ли у нас ресурсы?
  • Делать или не делать?

Есть еще много факторов. Я предлагаю просто:

Следуйте своему чутью😎

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

  • Изучите свою отрасль и конкурентную среду.
  • Изучите стратегию вашей организации. (Если вы, как и я, не совсем понимаете, что такое стратегия в деловом мире, я очень рекомендую книгу Игра на победу: как стратегия действительно работает А. Г. Лафли и Роджера Л. Мартина.)
  • Согласуйте проект с OKR организации.
  • Поговорите с дизайнерами о потребностях пользователей и болевых точках в их исследованиях.
  • Поговорите с менеджерами проекта (PM) или владельцами продукта (PO) об исследовании рынка.
  • Визуализируйте портфель проектов вашей организации. Просто взглянув на него, вы лучше поймете баланс между краткосрочными и долгосрочными обязательствами, распределением команды/проекта и буфером для адаптации.

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

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

Как выглядит успех?

Визуализация того, как выглядит успех на раннем этапе, поможет вам во многих отношениях:

  • Укрепите свое внутреннее чувство о проекте.
  • Более четко сообщайте другим о цели и согласовании с OKR.
  • Разработайте KPI для измерения прогресса и воздействия.

Мне нравится использовать подход Amazon «Работать в обратном направлении», чтобы изложить свои мысли в пресс-релизе. Это отличный способ привести людей в такое же настроение, просто увидев, что происходит после финиша.

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

  • Эпопея проекта или обзор.
  • Макеты дизайна пользовательского интерфейса.
  • Проекты инженерных систем.
  • KPI-аналитика.

Как отправить его как можно скорее?

«Отправляемся учиться».

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

  • ориентированный на человека и ориентированный на пользователя.
  • опирается на итерации обратной связи и обучения.
  • измеримый.

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

Дизайн-спринт — еще один отличный инструмент для решения проблемы и начала исследования. Самое главное, это весело🤩

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

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

А как насчет анализа KPI?

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

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

Существует ли мониторинг производительности?

Технические характеристики — это еще одна возможность включить инженерный контекст в обсуждение следующих итераций.

В целом существует два вида мониторинга:

  • Мониторинг реальных пользователей (RUM)
  • Синтетический мониторинг

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

Вот несколько полезных инструментов для мониторинга:

Должен ли я программировать в качестве главного инженера-программиста?

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

Многие главные инженеры имеют различные мнения и опыт, но я искренне верю, что если программирование — это ваше ремесло и вам это нравится, вам следует кодировать. Вопрос скорее в том, когда и где вам следует писать код.

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

Модель предполагает, что существует 4 типа стилей лидерства, и вы можете гибко выбирать стили руководства в зависимости от ситуации.

Я думаю, что для ситуаций поддержки и коучинга лучшее место и время для кода:

  • Прототипирование.
  • Хакатон.
  • Инструментарий для разработчиков.
  • Визуализация данных.

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

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

Последние мысли

Мы коснулись вопросов, которые я считаю полезными при планировании:

  • Это правильный проект?
  • Как выглядит успех?
  • Как отправить его как можно скорее?
  • Как насчет анализа KPI?
  • Имеется ли мониторинг производительности?
  • Должен ли я программировать как главный инженер-программист?

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

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

Рекомендации

Статьи

Книги

Инструменты

Want to Connect?
This article was originally posted on Daw-Chih’s website.