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

Кто ты?


При­вет! Меня зовут Фёдор Бор­щёв, и по чет­вер­гам я буду вме­сте с Васей и Юрой давать советы о раз­ра­ботке. Вот уже 10 лет я руко­вожу про­грам­ми­стами, поэтому я буду больше гово­рить об управ­ле­нии раз­ра­бот­кой, чем о коде.

Пара фак­тов обо мне:

  • я тех­ни­че­ский дирек­тор в Где­Ма­те­ри­але — стар­тапе, кото­рый даёт доступ рыноч­ным постав­щи­кам строй­ма­те­ри­а­лов к круп­ными заказ­чи­ками — застрой­щи­кам и ремонтникам;
  • я соос­но­ва­тель Руметра — един­ствен­ной базы новостроек с хоро­шим дизайном;
  • стал­ки­вался с мно­же­ством про­ек­тов, умер­ших из‑за раз­ра­ботки, часть из них загу­бил соб­ствен­ными руками;
  • веду блог и канал в Теле­граме.

К управ­ле­нию при­шёл через про­грам­ми­ро­ва­ние. За про­фес­си­о­наль­ную карьеру напи­сал код для мно­же­ства систем: плат­форму для «пар­синга интер­нета», систему онлайн‑тор­гов, лич­ный каби­нет сту­дента англий­ского, систему учета резуль­та­тов в трофи‑рей­дах, ней­ро­сеть для рас­краски черно‑белых фото­гра­фий, модуль склад­ского учета для интер­нет‑мага­зи­нов и мно­же­ство скрип­тов для авто­ма­ти­за­ции. До сих пор по 10 часов в неделю я пишу ком­мер­че­ский код на Питоне и Яваскрипте.

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

В коман­дах я делаю ставку на людей, инфра­струк­туру и здра­вый смысл. Вме­сто жёст­ких «завод­ских» про­цес­сов, на всех про­ек­тах внед­ряю ува­же­ние к лич­ному вре­мени, тре­бую TDD и помо­гаю команде авто­ма­ти­зи­ро­вать все, что только можно.

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

В при­ня­тии реше­ний сле­дую клас­си­че­ским рабо­там Питера Дру­кера, Эли­яху Гол­драдта и Ицх­ака Адизеса. Вни­ма­тельно при­слу­ши­ва­юсь к авто­рам, кото­рые раз­ви­вают менедж­мент как науку, вроде Фре­де­рика Лалу с его «бирю­зо­выми» организациями.

О чём меня стоит спрашивать:

  • о про­екте как про­дукте — как резать фичи на основе мет­рик и экс­пе­ри­мен­тов; как не тро­гая раз­ра­ботку понять, зара­бо­тает фича или нет;
  • о команде — как отли­чить хоро­шего про­грам­ми­ста от пло­хого; как сде­лать, чтобы участ­ни­кам было ком­фортно рабо­тать вме­сте; по каким прин­ци­пам раз­де­лять боль­шие команды на маленькие;
  • о под­хо­дах к напи­са­нию чистого кода — TDD/BDD; мет­рики каче­ства; как под­дер­жи­вать кодо­вую базу в чистоте и что делать, если уна­сле­до­ван­ный код мешает работать;
  • об инфра­струк­туре и девопсе — авто­ма­ти­за­ция, кла­стеры, CI/CD и мониторинг;
  • о раз­ви­тии про­грам­ми­ста — что учить, чтобы оста­ваться вос­тре­бо­ван­ным на рынке труда, в какую ком­па­нию пойти рабо­тать, как стать тимлидом;
  • о том, почему «в срок» важ­нее, чем «быстро»; почему время стоит дороже денег, и где брать энер­гию для дости­же­ния целей.

Пишите! В вопро­сах упо­ми­найте моё имя, чтобы я его сразу уви­дел. Напри­мер, «Вопрос Фёдору: рас­скажи, почему про­грам­ми­сты сры­вают сроки?»

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

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

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

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

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

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

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




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

2 Хочу научиться сторителлингу 10 Хочу научиться сторителлингу 2 2