x
 
Степан Чельцов
18 июля 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

У меня к тебе просьба осветить вопрос постановки задачи разработчику, который знает проект и для того, который не знает и придёт на замену первому. Как менеджеру ставить задачи так, чтобы ротация в команде не заставляла пережёвывать все задачи устно по 100 раз?


Степан!

Глав­ный инстру­мент пере­дачи зна­ний между раз­ра­бот­чи­ками — это код‑ревью. Пусть более опыт­ные раз­ра­бот­чики смот­рят код менее опыт­ных коллег.

Код‑ревью можно начи­нать и до созда­ния пулл‑рек­ве­ста: начи­найте сопро­вож­дать нович­ков ещё на этапе поста­новки задачи. Более опыт­ные раз­ра­бот­чики пояс­нят вещи, кото­рые кажутся оче­вид­ными тем, кто уже давно рабо­тает над про­ек­том — пока­жут дизай­нер­ские чек­ли­сты, рас­ска­жут об особо хруп­ких местах в коде, поде­лятся при­ня­тыми на про­екте мето­ди­ками реше­ния типо­вых задач.

Чтобы не нара­щи­вать фак­тор авто­буса, пере­бра­сы­вайте про­грам­ми­стов с про­екта на про­ект. Пона­чалу это кажется слож­ным, но если вы сле­дите за каче­ством кода (а вы же сле­дите, правда?), то про­грам­ми­сты без про­блем погру­жа­ются в сосед­ние про­екты — такая смена дея­тель­но­сти даже помо­гает им отдох­нуть от работы, кото­рая могла поднадоесть.

Под­ход «все знают всё» исклю­чает ситу­а­цию, когда раз­ра­бот­чик, ска­жем, забо­лел, и вся работа встала. Или когда один чело­век пере­гру­жен рабо­той, а дру­гие сидят без дела, потому что не зна­комы с про­ек­тами пер­вого. С боль­шими про­ек­тами такой под­ход тоже рабо­тает — вы про­сто пере­бра­сы­ва­ете раз­ра­бот­чи­ков между частями одного про­екта, ска­жем с веб‑админки поис­ко­вый дви­жок или на инте­гра­цию с банком.

А ещё, ста­рай­тесь не раз­ду­вать объём зна­ний в ком­па­нии. Под­дер­жи­вайте оди­на­ко­вый стек тех­но­ло­гий: если рабо­та­ете на ПХП, избе­гайте Питона. Если спе­ци­а­ли­зи­ру­е­тесь на Ворд­прессе — не бери­тесь за Бит­рикс. При­ме­няйте побольше фрейм­вор­ков и гото­вых биб­лио­тек — код в них стан­дар­ти­зо­ван: вновь при­шед­ший спе­ци­а­лист с боль­шей веро­ят­но­стью будет знать какой‑нибудь Yii, чем вашу внут­рен­нюю MVC‑разработку.

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

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

Вот такой веб 2.0.

Существует ли способ проверить компетентность веб-разработчика, если сам ничего не понимаешь в этом? Где провести границу MVP? 1 Как организовать работу удалённой команды разработчиков? Как донести подход HADI до руководства? 4




Недавно всплыло

4 10 дизайнерских товаров японских студий 2 2 2