Человекоцентричный подход
TL;DR
- 👑 Доставка королева.
- 🔭 Визуализируйте и определяйте успех на ранней стадии.
- 🤹 Не забудьте включить мониторинг производительности и анализ KPI.
- 🎯 Главный инженер – это руководящая роль. Подумайте о своем участии в проекте.
Для меня работа в качестве главного инженера-программиста — это сближение инженеров, бизнеса и людей.
Обычно вы один из первых технических представителей в организации, которые узнают о проекте в качестве главного инженера, и вам нужно вести внутренний диалог, чтобы продолжить или отказаться от него. Есть много вещей, которые следует учитывать с точки зрения бюджета времени, ресурсов, общения с заинтересованными сторонами и даже вашего собственного участия, когда дело доходит до планирования.
Поэтому я хочу поделиться с вами тем, что я думаю о планировании в качестве главного инженера, и какие важные вопросы следует задать на этапе планирования проекта.
Это правильный проект?
Вы услышите о проекте в разной степени зрелости в зависимости от того, как ваша организация обычно генерирует бизнес-идеи. Это может варьироваться от наблюдения за потребностью потенциального пользователя до «нам это нужно через три месяца». Несмотря на это, упрощенный ход мыслей выглядит так:
- Делать или не делать?
- Если «делать», то правильное ли это время?
- Какова инженерная сложность?
- Как усилия?
- Есть ли у нас ресурсы?
- Делать или не делать?
Есть еще много факторов. Я предлагаю просто:
Следуйте своему чутью😎
Обычно у вас будет интуиция, волнение или энергичное чувство, чтобы сказать «да» проекту. Чтобы развить интуицию с течением времени, есть несколько упражнений, которые я считаю очень полезными, чтобы сформулировать свое инженерное мнение:
- Изучите свою отрасль и конкурентную среду.
- Изучите стратегию вашей организации. (Если вы, как и я, не совсем понимаете, что такое стратегия в деловом мире, я очень рекомендую книгу Игра на победу: как стратегия действительно работает А. Г. Лафли и Роджера Л. Мартина.)
- Согласуйте проект с OKR организации.
- Поговорите с дизайнерами о потребностях пользователей и болевых точках в их исследованиях.
- Поговорите с менеджерами проекта (PM) или владельцами продукта (PO) об исследовании рынка.
- Визуализируйте портфель проектов вашей организации. Просто взглянув на него, вы лучше поймете баланс между краткосрочными и долгосрочными обязательствами, распределением команды/проекта и буфером для адаптации.
Если вы не уверены в том, как расставить приоритеты, вы можете вместе со своей командой разработать Матрицу приоритетов, чтобы выяснить, на каком этапе находится проект. Матрица приоритетов выглядит так:
Обратите внимание, что голосование, основанное на экспертных знаниях, имеет решающее значение в этом процессе, поскольку оно покажет, как люди в разных дисциплинах думают о важности и срочности проектов. Это невидимая третья ось матрицы.
Как выглядит успех?
Визуализация того, как выглядит успех на раннем этапе, поможет вам во многих отношениях:
- Укрепите свое внутреннее чувство о проекте.
- Более четко сообщайте другим о цели и согласовании с OKR.
- Разработайте KPI для измерения прогресса и воздействия.
Мне нравится использовать подход Amazon «Работать в обратном направлении», чтобы изложить свои мысли в пресс-релизе. Это отличный способ привести людей в такое же настроение, просто увидев, что происходит после финиша.
Я использую пресс-релиз в качестве отправной точки для обсуждения и консолидации ссылок на документацию. Обычно включает:
- Эпопея проекта или обзор.
- Макеты дизайна пользовательского интерфейса.
- Проекты инженерных систем.
- KPI-аналитика.
Как отправить его как можно скорее?
«Отправляемся учиться».
Это стало моим руководящим принципом с тех пор, как я прочитал об этой цитате. GitHub разделяет ту же идею в своих принципах лидерства, и я думаю, что это мышление является основой бережливой и гибкой разработки программного обеспечения, потому что оно:
- ориентированный на человека и ориентированный на пользователя.
- опирается на итерации обратной связи и обучения.
- измеримый.
Мне нравится использовать Дизайн-мышление в качестве основы для размышлений о проблемах и о том, как выполнять итерации по всему проекту. В сочетании с пресс-релизом и ключевыми показателями эффективности это отличный способ проверить свои предположения и не сбиться с курса.
Дизайн-спринт — еще один отличный инструмент для решения проблемы и начала исследования. Самое главное, это весело🤩
Когда вы сталкиваетесь со сложным проектом, убедитесь, что ваши предложения по проектированию системы включают альтернативы, которые проще и быстрее построить. Это позволит командам работать быстрее.
Вывод здесь состоит в том, чтобы действительно сосредоточиться на передаче проекта в руки пользователей, а не на реализации полного решения.
А как насчет анализа KPI?
Очень полезно сопоставить бизнес-KPI и UX-KPI, чтобы лучше понять данные. Важно погрузиться в анализ с продакт-менеджерами и дизайнерами, чтобы выяснить направление следующей итерации.
Я изучил несколько базовых понятий в статистике, которые полезны для совместной работы с командами бизнес-аналитики и дизайна.
- Перестановочное тестирование
- p-значение
- А/Б тестирование
- A/B/n-тестирование
- Многовариантное тестирование
- Многорукий бандит
- Когда проводить многовариантные тесты вместо A/B/n-тестов
- Проблема многорукого бандита и ее решения
Существует ли мониторинг производительности?
Технические характеристики — это еще одна возможность включить инженерный контекст в обсуждение следующих итераций.
В целом существует два вида мониторинга:
- Мониторинг реальных пользователей (RUM)
- Синтетический мониторинг
RUM — это живые данные. Он рассказывает о реальном поведении пользователей и о том, как ваша система работает с течением времени. Синтетический мониторинг сообщает данные вашей системы в контролируемой среде, поэтому он подходит для статического анализа, регрессионного тестирования и тестирования производительности.
Вот несколько полезных инструментов для мониторинга:
Должен ли я программировать в качестве главного инженера-программиста?
Я считаю, что вы должны, но суть в том, чтобы расширить возможности инженеров и убедиться, что ваше участие не блокирует и не мешает итерациям.
Многие главные инженеры имеют различные мнения и опыт, но я искренне верю, что если программирование — это ваше ремесло и вам это нравится, вам следует кодировать. Вопрос скорее в том, когда и где вам следует писать код.
Мой коуч по лидерству познакомил меня с моделью под названием Ситуационное лидерство. Я использую его, чтобы думать о своем участии в проектах. Это выглядит так:
Модель предполагает, что существует 4 типа стилей лидерства, и вы можете гибко выбирать стили руководства в зависимости от ситуации.
Я думаю, что для ситуаций поддержки и коучинга лучшее место и время для кода:
- Прототипирование.
- Хакатон.
- Инструментарий для разработчиков.
- Визуализация данных.
Ваше намерение состоит в том, чтобы поддерживать определенный уровень участия и видимости проектов, чтобы оказывать поддержку в случае необходимости. Такие ситуации обычно случаются в важных проектах с более длительными временными рамками. Это также тип проектов, на которые вы тратите время, наставляя и спонсируя инженеров.
В ситуациях режиссуры, я думаю, лучше не писать код, потому что вы сильно вкладываетесь в направление проекта. Вы будете проводить много анализов и коммуникаций. Ручная работа часто отвлекает вас от вашего внимания.
Последние мысли
Мы коснулись вопросов, которые я считаю полезными при планировании:
- Это правильный проект?
- Как выглядит успех?
- Как отправить его как можно скорее?
- Как насчет анализа KPI?
- Имеется ли мониторинг производительности?
- Должен ли я программировать как главный инженер-программист?
Важно знать, что в этих вопросах нет определенного порядка. Вы можете думать о них в разной последовательности в зависимости от вашей ситуации.
Важно то, что в конце планирования у вас будет четкое представление о том, как повторить ваши предположения и представить проект пользователям.
Рекомендации
Статьи
- Подход Amazon Work Backwards — Quora
- Шаблон и пример пресс-релиза Amazon, работающего в обратном направлении — Ян Макаллистер
- Дизайн-мышление 101 — Nielsen Norman Group
- Почему дизайн-мышление работает — HBR
- Дизайн-мышление, объяснение — MIT
- Дизайн-спринт — ГВ
- Как мы используем «маленький корабль для быстрого создания новых функций на GitHub — Сообщество разработчиков»
- Тест перестановок: визуальное объяснение статистического тестирования — Джаред Уилбер
- Многорукий бандит — Оптимизация
- Проблема многорукого бандита и ее решения — Лилиан Венг
- A/B-тестирование — оптимизируем
- A/B/n Тестирование -Оптимизирую
- Многовариантное тестирование — Optimizely
- Когда проводить многовариантные тесты вместо A/B/n-тестов — CXL
- p-значение — Википедия
- Ситуационное лидерство: 4 стиля и качества
- Мониторинг данных телеметрии Formula 1 в Kubernetes в режиме реального времени с помощью Grafana, Apache Kafka и Strimzi — Paolo Patierno
- Ставь цели с помощью OKR — re:Work
- Использование матриц приоритизации для информирования UX-решений — Nielsen Norman Group
- Что такое цели и ключевые результаты (ОКР)? — асана
- Цели и ключевые результаты (ОКР) — GitLab
- Какие метрики и KPI используют эксперты для измерения эффективности UX? — ПользовательЗум
- Ключевые показатели эффективности (KPI) для оптимизации
- Показатели эффективности инженерных функций — GitLab
- Быть клеем — Таня Рейли
- Чем на самом деле занимаются штабные инженеры? — СтаффИнж
- Мониторинг производительности: RUM против синтетического мониторинга — MDN
- Тестирование производительности ПО — Википедия
- Тестирование производительности, нагрузочное тестирование и стресс-тестирование — Blazemeter
- Все, что вам нужно знать о стресс-тестировании вашего программного обеспечения — DZone
- Регрессионное тестирование — Википедия
- Статический анализ программ — Википедия
- От Frontend-разработчика до главного инженера-программиста — Доу-Чи Лиу
- Тайм-менеджмент — Википедия
Книги
- Штатный инженер: Лидерство за пределами управленческого пути — Уилл Ларсон
- Игра на победу: как на самом деле работает стратегия — А. Г. Лафли, Роджер Л. Мартин
Инструменты
- Клиника.js
- автопушка — GitHub
- Производительность API — MDN
- Кипарис.ио
- Тестовая библиотека
- Графана
- Гугл Маяк
- К6 — Гитхаб
Want to Connect? This article was originally posted on Daw-Chih’s website.