metrica
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

Вебинар: Трудности при интеграции SAST, как с ними справляться - 04.04

>
>
Про гребцов и программистов, или аналог…

Про гребцов и программистов, или аналогии в академической гребле и бизнесе по разработке программного обеспечения

03 Мар 2014

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

0239_Rowers_ru/image1.png

Рисунок 1 - Евгений Рыжков

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

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

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

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

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

0239_Rowers_ru/image2.png

Рисунок 2 – Парная гребля

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

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

0239_Rowers_ru/image3.png

Рисунок 3 - Восьмерка

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

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

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

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

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

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

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

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

Популярные статьи по теме


Комментарии (0)

Следующие комментарии next comments
close comment form