Руководство главного инженера-программиста по безболезненному планированию проектов

Подход, ориентированный на человека

TL;DR

• 👑 Доставка королева.

• 🔭 Визуализируйте и определяйте успех на ранней стадии.

• 🤹 Не забудьте включить мониторинг производительности и анализ KPI.

• 🎯 Главный инженер — это руководящая роль. Подумайте о своем участии в проекте.

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

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

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

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

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

• Делать или не делать?

• Если «сделать», это правильное время?

• Какова инженерная сложность?

• Как усилия?

• Есть ли у нас ресурсы?

• Делать или не делать?

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

Следуй за своей интуицией😎

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

• Изучите свою отрасль и конкурентную среду.

• Изучите стратегию вашей организации. (Если вы, как и я, не совсем понимаете, что такое «стратегия» в деловом мире, я настоятельно рекомендую книгу «[Игра на победу: как стратегия действительно работает]» (https://www.goodreads.com/book/show). /13586928-playing-to-win)» А. Г. Лафли и Роджера Л. Мартина.)

• Согласуйте проект с [OKR] организации (https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/).

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

• Поговорите с менеджерами проекта (PM) или владельцами продукта (PO) об исследовании рынка.

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

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

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

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

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

• Укрепите свое внутреннее чувство о проекте.

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

• Разработайте ключевые показатели эффективности для измерения прогресса и воздействия.

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

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

• Эпопея проекта или обзор.

• Мокапы дизайна пользовательского интерфейса.

• Проекты инженерных систем.

• Аналитика KPI.

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

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

Это стало моим руководящим принципом с тех пор, как я прочитал об этой цитате. [GitHub] (https://dev.to/mscccc/how-we-use-ship-small-to-rapidly-build-new-features-at-github-5cl9) разделяет ту же идею в своих принципах лидерства, и я думаю, что образ мышления является основой бережливой и гибкой разработки программного обеспечения, потому что он:

• ориентированный на человека и ориентированный на пользователя.

• питание от итераций обратной связи и обучения.

• измеримый.

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

[Design Sprint] (https://www.gv.com/sprint/) – еще один отличный инструмент для решения проблемы и начала исследования. Самое главное, это весело🤩

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

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

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

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

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

• [Тестирование перестановок] (https://www.jwilber.me/permutationtest/)

• p-значение

• A/B-тестирование

• A/B/n-тестирование

• [Многовариантное тестирование] (https://www.optimizely.com/optimization-glossary/multivariate-testing/)

• Многорукий бандит

• Когда проводить многовариантные тесты вместо A/B/n-тестов

• [Проблема многорукого бандита и ее решения] (https://lilianweng.github.io/posts/2018-01-23-multi-armed-bandit/)

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

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

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

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

• Синтетический мониторинг

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

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

• [Графана] (https://grafana.com/)

• [Google Lighthouse] (https://developers.google.com/web/tools/lighthouse)

• [автопушка] (https://github.com/mcollina/autocannon)

• [Кипарис] (https://www.cypress.io/)

• [K6] (https://github.com/grafana/k6)

• API производительности

• [Clinic.js] (https://clinicjs.org/)

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

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

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

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

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

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

• Прототипирование.

• Хакатон.

• Инструментарий для разработчиков.

• Визуализация данных.

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

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

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

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

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

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

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

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

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

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

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

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

Использованная литература

Статьи

• [Подход Amazon Work Backwards  — Quora] (https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management/answer/Ian-McAllister)

• [Шаблон и пример пресс-релиза Amazon, работающего в обратном направлении  —   Ян Макаллистер] (https://www.linkedin.com/pulse/working-backwards-press-release-template-example-ian-mcallister/)

• [Дизайн-мышление 101 — Nielsen Norman Group] (https://www.nngroup.com/articles/design-thinking/)

• [Почему дизайн-мышление работает — HBR] (https://hbr.org/2018/09/why-design-thinking-works)

• [Дизайн-мышление, объяснение — MIT] (https://mitsloan.mit.edu/ideas-made-to-matter/design-thinking-explained)

• [Дизайн-спринт — GV] (https://www.gv.com/sprint/)

• Как мы используем принцип «небольшого выпуска» для быстрого создания новых функций на GitHub — Сообщество разработчиков

• [Тест перестановок: визуальное объяснение статистического тестирования — Джаред Уилбер] (https://www.jwilber.me/permutationtest/)

• [Многорукий бандит — Оптимизируйте] (https://www.optimizely.com/optimization-glossary/multi-armed-bandit/)

• [Проблема многорукого бандита и ее решения  —   Лилиан Венг] (https://lilianweng.github.io/posts/2018-01-23-multi-armed-bandit/)

• [A/B-тестирование — Optimizely] (https://www.optimizely.com/optimization-glossary/ab-testing/)

• A/B/n Testing-Optimizely

• [Многовариантное тестирование — Optimizely] (https://www.optimizely.com/optimization-glossary/multivariate-testing/)

• Когда проводить многовариантные тесты вместо A/B/n-тестов — CXL

• [p-значение — Википедия] (https://en.wikipedia.org/wiki/P-значение)

• Ситуационное лидерство: 4 стиля и качества

• Мониторинг данных телеметрии Formula 1 в Kubernetes в режиме реального времени с помощью Grafana, Apache Kafka и Strimzi — Paolo Patierno

• Установите цели с помощью OKR — re:Work

• Использование матриц приоритезации для информирования решений UX — Nielsen Norman Group

• Что такое цели и ключевые результаты (OKR)? — асана

• Цели и ключевые результаты (OKR) — GitLab

• Какие показатели и KPI используют эксперты для измерения эффективности UX? — UserZoom

• [Ключевые показатели эффективности (KPI) для оптимизации] (https://cxl.com/blog/key-performance-indicators-kpi/)

• [Показатели производительности технических функций — GitLab] (https://about.gitlab.com/handbook/engineering/performance-indicators/)

• Being Glue — Таня Рейли

• Чем на самом деле занимаются штатные инженеры? — StaffEng

• Мониторинг производительности: RUM vs синтетический мониторинг — MDN

• Тестирование производительности программного обеспечения — Википедия

• Тестирование производительности, нагрузочное тестирование и стресс-тестирование — Blazemeter

• Все, что вам нужно знать о стресс-тестировании вашего программного обеспечения — DZone

• Регрессионное тестирование — Википедия

• [Анализ статических программ — Википедия] (https://en.wikipedia.org/wiki/Static_program_analysis)

• От разработчика внешнего интерфейса до главного инженера-программиста  —  Daw-Chih Liou

• Тайм-менеджмент — Википедия

Книги

• [Штатный инженер: лидерство за пределами управленческого пути  —  Уилл Ларсон] (https://staffeng.com/book)

• [Игра на победу: как на самом деле работает стратегия  — А. Г. Лафли, Роджер Л. Мартин] (https://www.goodreads.com/book/show/13586928-playing-to-win)

Инструменты

• [Clinic.js] (https://clinicjs.org/)

• [autocannon — GitHub] (https://github.com/mcollina/autocannon)

• API производительности — MDN

• [Cypress.io] (https://www.cypress.io/)

• [Библиотека тестирования] (https://testing-library.com/)

• [Графана] (https://grafana.com/)

• [Google Lighthouse] (https://developers.google.com/web/tools/lighthouse)

• [K6 — GitHub] (https://github.com/grafana/k6)

Эта статья изначально была размещена на [веб-сайте Доу-Чи] (https://dawchihliou.github.io/articles/how-to-plan-a-project-as-a-principal-software-engineer).