Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
По роду своей деятельности я часто общаюсь с программистами. Моя компания занимается разработкой, продвижением и продажей собственного программного продукта. Это статический анализатор кода PVS-Studio. Наши продукты предназначены для программистов и позволяют найти ошибки в исходном коде приложений путем автоматического анализа этого кода.
Рисунок 1 - Евгений Рыжков
Естественно, что и на работе я общаюсь со своими программистами, и пользователи наши – программисты. Поэтому образ мышления программиста мне прекрасно понятен. Да я и сам по образованию программист, так что когда-то это был и мой образ мышления.
И чем больше я общаюсь с программистами, тем больше вижу стопроцентную аналогию между работой программистов и, как это ни странно, академической греблей. Что я имею ввиду? Об этом и будет статья.
Академическая гребля – очень интересный вид спорта. Википедия говорит нам:
Спортсмены находятся в лодках и гребут веслами, используя мышцы спины, рук и ног проходя дистанцию спиной вперед, в отличие от гребли на байдарках и каноэ. ... Парная гребля выполняется двумя веслами, распашная гребля — одним веслом. Состав лодки бывает из одного, двух, четырёх или восьми гребцов.
Если мы посмотрим на фотографии гребцов, то заметим интересную вещь.
Рисунок 2 – Парная гребля
Если в гребле участвует небольшое количество гребцов, например, двое, то они прекрасно справляются сами, вдвоем.
А если в одной лодке сидит четверо или, тем более, восемь гребцов, то у них появляется в команде еще один человек: рулевой или впередсмотрящий. Ничего не напоминает из программирования?
Рисунок 3 - Восьмерка
Когда программист работает над задачей один или с коллегой, они прекрасно могут справиться самостоятельно. Но как только в проекте появляется чуть большее количество человек, сразу должен появиться так называемый руководитель проекта. Или project manager (PM) в английской терминологии. В отличие от технического лидера команды, который принимает технические решения, руководитель проекта нужен для другого. Во-первых, он определяет "направление движения": какие функции стоит добавить в продукт, а какие нет. А, во-вторых, он задает "ритм гребков": с какой частотой выпускать новую версию продукта. Проще говоря, отвечает на вопрос: "Когда релиз?" А если речь идет о заказной разработке программного обеспечения, то еще и общается с заказчиком.
Более того, иногда у гребцов есть ориентиры куда плыть в виде дорожки или буйков. У программистов вроде бы тоже есть ориентиры: список пожеланий от пользователей, список известных ошибок. Да и любой программист вам назовет сходу десять задач в проекте, которые надо решить в самую первую очередь! Однако если на все эти вопросы-ответы будут давать программисты сами себе, то они уплывут в средиземное море. Ведь они "гребут спиной вперед" и не видят, куда плывут. Другими словами, будут разрабатывать продукт годы и никогда не выпустят следующую версию.
Однако в отличие от гребцов, которым на 100% понятно, зачем им нужен рулевой, программисты зачастую считают руководителя проекта "лишним человеком". Почему? Наверное, потому, что программисты неправильно воспринимают его как бестолкового начальника, который сам ничего не делает, а других "учит жизни".
Приведу несколько примеров.
В ходе работы над продуктом программист получает задачу – реализовать некоторую функцию. В процессе реализации программист понимает, что можно сделать еще и вот такую функцию, причем совсем легко, потратив лишь пару дней. Он принимает решение быстренько реализовать и ее, ведь по мнению программиста он молодец, сам сделал "классную штуку", за которую его обязательно похвалит начальник! Правда, в процессе реализации выяснилось, что одна базовая вещь работает не совсем так, как ожидается, поэтому он быстро (всего за неделю!) ее переписал. Ну ведь молодец же, нет?
Нет! В этом примере виноват, конечно, впередсмотрящий, который проглядел, что программист сам себе нашел задачу (и не одну) и стал ей заниматься. Руководитель проекта не должен был этого допустить, так как возможно дополнительная реализованная функциональность никому не нужна, а ошибки в базовой части никогда не возникают, так как не может быть таких входных параметров. Но программисту всегда интересно решать всякие сложные задачи, поэтому он не понимает, что "гребет не туда".
Другой пример. Потенциальный клиент интересуется продуктом. Он даже готов его купить, но вот поведение одной функции ему не нравится, и он просит ее переделать. Программист с радостью ее переделывает (ведь он помог человеку!), сделка проходит (программист уже ждет премию!), а в итоге руководитель проекта ругает программиста за то, что он сделал. Почему? Да потому что изменив поведение этой функции под одного клиента, программист забыл, что сломал ее работу для 100 других существующих клиентов. Конечно и в этом примере виноват руководитель проекта, что дал инициативу программисту.
Какие из этого можно сделать выводы? У меня не будет выводов, у меня будет лишь просьба к программистам. Когда вы сидите в лодке с коллегами и гребете спиной вперед, помните одну вещь: если каждый будет сам определять направление движения и ритм гребков, то вы или уплывете в средиземное море, или, что скорее всего, никуда не уплывете. А ведь нам всем надо плыть к нашей цели, верно?
0
0
0
0