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

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

Насколько я понимаю, ты — за первый вариант: считаешь, что разработчик, который не думает, а просто делает — не нужен. Можешь рассказать об этом?


Владимир!

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

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

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

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

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

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

Комментарии

Дмитрий Воропаев
29 ноября 2019

Как убедить или научить разработчика думать о бизнесовой части задачи?


29 ноября 2019

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

Виктор Кущ
29 ноября 2019

Если всё переложить на программиста, то бизнес начитает забивать на постановку задачи и всё скатывается к «разберись сам». Хороший баланс — это нормально собранное техническое задание и вдумчивое прочтение программистом с вопросами по corner cases. А задача менеджмента — следить за этим балансом.

Дима Шишикин
30 ноября 2019

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

Андрей Бобков
4 января 2020

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


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

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

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

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

Как объяснить значимость фичи разработчику? 1 Расскажите об обязанностях технического директора в бюро. Вторая часть: встречи один на один Как быть, если твой руководитель некомпетентнее или незаинтересованнее тебя? Как искать баланс между пользой для команды и пользой для себя? 1




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

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