Я начал свою карьеру в качестве программиста по разработке продуктов, и до тех пор, пока я не ушел из компании, я работал руководителем группы, отвечая за большой проект с несколькими программистами.
В настоящее время я работаю инженером-фрилансером и участвую в разработке различных продуктов. Я напишу о командном развитии, которое, по моему мнению, было очень хорошим.
Во-первых, паршивая разработка команды, основанная на моем опыте
Перед этим я напишу о командном развитии, которое я считал нелепым, исходя из своего предыдущего опыта. Проще говоря, самое страшное, когда программист думает продакт-менеджеру: «Я не могу разработать продукт без этого человека».
- Пусть программисты договариваются с заказчиками.
- Информация, связанная с разработкой, такая как изменения спецификаций, не может быть передана внутри команды.
Это позволяет программистам проводить время с клиентами, не передавая их отзывы должным образом. Я не разбираюсь в технической стороне дела, поэтому присутствие программиста неизбежно, но, кроме технических вопросов, я позволяю программисту делать все, например, сообщать об общем состоянии разработки и корректировать общий график, и я м подрабатываю. Я видел ПМ.
Нагрузка на участников развития возрастет, и более того, доверие участников будет потеряно. Программисты хотят сосредоточиться на разработке и не должны позволять программистам выполнять работу по управлению проектами.
Кроме того, некоторые люди не дают отзывов и имеют стиль ответов, когда их спрашивают, например, расширяют, когда их спрашивают программисты. Это слишком неэффективно, и я хочу спросить, зачем мне вообще встречаться с заказчиком.
Кроме того, что касается технологии, начало реализации является наихудшей ситуацией, хотя дизайн еще не определен. Пожалуйста, не стесняйтесь назначать ответственного за каждое функциональное требование до того, как будет принято решение о дизайне! Такова ситуация.
Поскольку дизайн не является унифицированным для каждой функции, затраты на расшифровку кода будут понесены для ответа других участников, и вероятность неправильной реализации возрастет. Кроме того, создается дублированный исходный код, что снижает удобство сопровождения и расширяемость.
Кроме того, если дизайн не определен, производительность программиста не увеличится, потому что реализация будет неопределенной, например: «Нет ли проблем с этой реализацией в целом?»
Невыполнение этого требования создаст очаг дефектов, поэтому мы должны назначить кого-то, кто возглавит техническую сторону и сделает дизайн должным образом.
Что такое хорошее развитие команды?
Теперь я напишу о том, что именно является хорошим командным развитием, а не опытом. Я почувствовал это, когда увидел команду, к которой присоединился в качестве внештатного инженера. На мой взгляд, хорошее развитие команды выглядит следующим образом:
- PM ведет переговоры с клиентами и твердо формирует обратную связь
- Человек, который ведет техническую сторону, твердо решает дизайн
- Проводит регулярные встречи и утверждает продукт
PM ведет переговоры с клиентами и активно формирует отзывы.
Я думаю, что это само собой разумеющееся, но PM ведет переговоры с заказчиком, чтобы определить требования к продукту и дает команде обратную связь по спецификациям. Программисты хотят сосредоточиться на разработке, поэтому важно по возможности избегать переговоров с клиентами.
PM должен обобщать истории, услышанные от заказчика, и предоставлять обратную связь участникам разработки на регулярных встречах.
Это отличный способ предотвратить безжалостный поток требований от ваших клиентов, которые обрушатся на ваших программистов. В таком случае, чем технически подкованнее ПМ, тем лучше.
Если вы не знаете технологию, то при консультации с заказчиком о возможности ее реализации необходимо уточнить у программиста осуществимость. ПМ и программист должны оплатить работу по подтверждению.
Не страшно проверить у программиста, но чем меньше стоимость, тем больше времени можно уделить разработке, поэтому мы хотим по возможности этого избежать.
Реализовать функции, запрошенные заказчиком как PM, при наличии навыков ответить «какой набор разработки и что требуется, масштаб разработки (время работы, сложность, риск)», будет гладко. Я чувствовал, что разработка продукта может продолжаться.
Человек, отвечающий за техническую сторону, принимает твердое решение о дизайне
Имея всего одного человека, который может спроектировать весь продукт, у вас может быть довольно хорошая командная разработка. В случае веб-разработки, если вы выберете интерфейс, серверную часть, базу данных, облачный сервер, сторонний сервер и т. д., а также определитесь с архитектурой, разработка может пройти гладко.
Однако, если вы сделаете только первоначальный дизайн, и он закончится, код станет беспорядочным по пути, поэтому необходимо проверить, был ли реализован неправильный дизайн в обзоре участника.
Если разработчикам нужна помощь в понимании дизайна, они должны подготовить пример кода, реализованного в соответствии с рекомендациями по дизайну. Желательно, чтобы один вариант использования реализовал пример кода.
С помощью примера кода программисты могут читать между строк и реализовывать его, чтобы понять дизайн из потока обработки.
Кроме того, если участнику нужна помощь с техническим аспектом, также важно помочь ему, представив парное программирование или справочную литературу.
Просвещение участников разработки уменьшит объем работы в целом, поэтому я считаю, что это нужно делать на опережение.
Проводите регулярные встречи для проверки продуктов
Это регулярное собрание раз в неделю и признание статуса продукта внутри команды. Повестка дня собрания следующая.
- Обратная связь со встреч с клиентами
- Подтверждение прогресса каждого участника и что делать дальше
- Подтверждение технических проблем и ограничений функций
Проведите видеоконференцию или офлайн-встречу (в течение 1 часа) для подтверждения.
Прислушиваясь к подлинным голосам участников, мы можем узнать, полностью ли они осведомлены о спецификациях продукта, который предстоит разработать, и нужна ли им помощь по техническим вопросам. Как PM, я также должен делиться отзывами, что является отличной возможностью обобщить требования.
Дополнительно: уловки, чтобы поднять напряжение среди программистов
В зависимости от человека это может не волновать вас, но для кого-то вроде меня, кто чувствует себя одиноким и ласкает меня, меня мотивировали следующие вещи.
- Используйте новые технологии
- Используйте LGTM при утверждении запроса на вытягивание (изображение LGTM)
- Используйте штампы эмодзи в сообщениях чата, чтобы передать то, что вы слушаете
Я написал о том, как выглядит хорошая командная разработка с точки зрения программиста, основываясь на своем опыте. Я многому научился, работая с моей командой разработки, и мне понравилось работать с ними. Некоторые люди отлично разбираются в технологиях, продуктах и управлении командой. Вы научили меня тому, как выглядит хорошее командное развитие.
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .