Отправляет email-рассылки с помощью сервиса Sendsay

Новости мира гаджетов и hi-tech-бизнеса

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 185 RSS
←   Март 2014   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
30.03.2014
11:16:25
20:01:42
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://biznes-angel.livejournal.com/
Открыта: 17-02-2013
Адрес автора: business.school.biznesangel-owner@subscribe.ru

Автор
Виниту

Статистика

185 подписчиков
0 за неделю
←   Все выпуски   →

Про греблю и программистов


Про греблю и программистов
2014-03-03 00:00

По роду своей деятельности я часто общаюсь с программистами. Дело в том, что моя компания занимается разработкой, продвижением и продажей собственных программных продуктов. Это статические анализаторы кода PVS-Studio и CppCat. Наши продукты предназначены для программистов и позволяют найти ошибки в исходном коде приложений путем автоматического анализа этого кода.

Естественно, что и на работе я общаюсь со своими программистами, и пользователи наши – программисты. Поэтому образ мышления программиста мне прекрасно понятен. Да я и сам по образованию программист, так что когда-то это был и мой образ мышления.

И чем больше я общаюсь с программистами, тем больше вижу стопроцентную аналогию в работе программистов и, как это ни странно, в академической гребле. Что я имею ввиду? Об этом и будет статья.

Академическая гребля – очень интересный вид спорта. Википедия говорит нам:

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

Если мы посмотрим на фотографии гребцов, то заметим интересную вещь.

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

А если в одной лодке сидит четверо или тем более восемь гребцов, то у них появляется в команде еще один человек: рулевой или впередсмотрящий. Ничего не напоминает из программирования?

Когда программист работает над задачей один или с коллегой, они прекрасно могут справиться самостоятельно. Но как только в проекте появляется чуть большее количество человек, сразу должен появиться так называемый руководитель проекта. Или project manager (PM) в английской терминологии. В отличие от технического лидера команды, который принимает технические решения, руководитель проекта нужен для другого. Во-первых, он определяет «направление движения» – какие функции стоит добавить в продукт, а какие нет. А, во-вторых, он задает «ритм гребков» – с какой частотой выпускать новую версию продукта. Проще говоря, отвечает на вопрос: «Когда релиз?». А если речь идет о заказной разработке программного обеспечение, то и общается с заказчиком.

Более того, иногда у гребцов есть ориентиры, куда плыть, в виде дорожки или буйков. У программистов вроде бы тоже есть ориентиры – есть список пожеланий от пользователей, есть список известных ошибок. Да и любой программист вам назовет сходу десять задач в проекте, которые надо решить в самую первую очередь! Однако если на все эти вопросы ответы будут давать программисты сами себе, то они уплывут в Средиземное море. Ведь они «гребут спиной вперед» и не видят, куда плывут. Другими словами, будут разрабатывать продукт годы и никогда не выпустят следующую версию.

Однако в отличие от гребцов, которым на 100% понятно, зачем им нужен рулевой, программисты зачастую считают руководителя проекта «лишним человеком». Почему? Наверное, потому, что программисты неправильно воспринимают его как бестолкового начальника, который сам ничего не делает, а других «учит жизни».

Приведу несколько примеров.

В ходе работы над продуктом, программист получают задачу – реализовать некоторую функцию. В процессе реализации программист понимает, что можно сделать еще и вот такую функцию, причем совсем легко, потратив лишь пару дней. Он принимает решение быстренько реализовать и ее – ведь по мнение программиста он молодец, сам сделал «классную штуку», за которую его обязательно похвалит начальник! Правда в процессе реализации выяснилось, что одна базовая вещь работает не совсем так, как ожидается, поэтому он быстро (всего за неделю!) ее переписал. Ну ведь молодец же, нет?

Нет! В этом примере виноват конечно впередсмотрящий, который проглядел, что программист сам себе нашел задачу (и не одну) и стал ей заниматься. Руководитель проекта не должен был этого допустить, так как возможно дополнительная реализованная функциональность никому не нужна, а ошибки в базовой части никогда не возникают, так как не может быть таких входных параметров. Но программисту всегда интересно решать всякие сложные штуки, поэтому он не понимает, что «гребет не туда».

Другой пример. Потенциальный клиент интересуется продуктом. Он даже готов его купить, но вот поведение одной функции ему не нравится, и он просит ее переделать. Программист с радостью ее переделывает (ведь он помог человеку!), сделка проходит (программист уже ждет премию!), а в итоге руководитель проекта ругает программиста за то, что он сделал. Почему? Да потому что изменив поведение этой функции под одного клиента, программист забыл, что сломал ее работу для 100 других существующих. Конечно, и в этом примере виноват руководитель проекта, что дал инициативу программисту.

Какие из этого можно сделать выводы? У меня не будет выводов, у меня будет лишь просьба к программистам. Когда вы сидите в лодке с коллегами и гребете спиной вперед, помните одну вещь. Если каждый будет сам определять направление движения и ритм гребков, то вы или уплывете в Средиземное море, или, что скорее всего, никуда не уплывете. А ведь нам всем надо плыть к нашей цели, верно? 
В избранное