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

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

Во-первых, паршивая разработка команды, основанная на моем опыте

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

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

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

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

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

Кроме того, что касается технологии, начало реализации является наихудшей ситуацией, хотя дизайн еще не определен. Пожалуйста, не стесняйтесь назначать ответственного за каждое функциональное требование до того, как будет принято решение о дизайне! Такова ситуация.

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

Кроме того, если дизайн не определен, производительность программиста не увеличится, потому что реализация будет неопределенной, например: «Нет ли проблем с этой реализацией в целом?»

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

Что такое хорошее развитие команды?

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

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

PM ведет переговоры с клиентами и активно формирует отзывы.

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

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

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

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

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

Реализовать функции, запрошенные заказчиком как PM, при наличии навыков ответить «какой набор разработки и что требуется, масштаб разработки (время работы, сложность, риск)», будет гладко. Я чувствовал, что разработка продукта может продолжаться.

Человек, отвечающий за техническую сторону, принимает твердое решение о дизайне

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

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

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

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

Кроме того, если участнику нужна помощь с техническим аспектом, также важно помочь ему, представив парное программирование или справочную литературу.

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

Проводите регулярные встречи для проверки продуктов

Это регулярное собрание раз в неделю и признание статуса продукта внутри команды. Повестка дня собрания следующая.

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

Проведите видеоконференцию или офлайн-встречу (в течение 1 часа) для подтверждения.

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

Дополнительно: уловки, чтобы поднять напряжение среди программистов

В зависимости от человека это может не волновать вас, но для кого-то вроде меня, кто чувствует себя одиноким и ласкает меня, меня мотивировали следующие вещи.

  • Используйте новые технологии
  • Используйте LGTM при утверждении запроса на вытягивание (изображение LGTM)
  • Используйте штампы эмодзи в сообщениях чата, чтобы передать то, что вы слушаете

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

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .