The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
На Zerocracy мы работаем в распределенных командах и вся наша коммуникация происходит в рамках задач. Кроме того, мы поддерживаем инициативу каждого разработчика на каждом проекте сообщать о найденных ошибках. Мы даже платим за каждую найденную ошибку. Иногда я вижу сообщения об ошибках вроде “Может кто-нибудь объяснить мне, как спроектировать этот модуль?” или даже “Я никогда не использовал эту библиотеку; пожалуйста, помогите мне начать.”. Мой обычный ответ такой: “Это не школа, здесь никто не будет тебя учить!”. Я понимаю, что это может показаться жестким для большинства разработчиков, которые только начинают работать с нами, поэтому здесь я постараюсь объяснить, почему такое отношение имеет смысл и полезно как для программистов, так и для проекта.
Отказ от ответственности: я говорю о программных проектах, которые PMBOK определяет как “временные усилия, предпринимаемые для создания уникальных продуктов, услуг или результатов”. Если ваша команда занимается непрерывной разработкой или обслуживанием программного обеспечения, это понятие может не быть актуальным.
Независимо от того, насколько неприятно это может быть, давайте смотреть правде в глаза: каждый программный проект - это бизнес, и мы, разработчики, являемся его ресурсами. Как бетон, дерево и стекло - ресурсы, необходимые для строительства дома, который также является бизнес-активностью. Независимо от того, насколько мы думаем о себе как о семье, которая весело проводит время вместе и пишет код, потому что нам это нравится, каждый бизнес смотрит на это совершенно иначе.
Проекту нужно, чтобы мы производили классы, строки кода, методы, функции, файлы и функциональность. Затем проект может превратить их в довольных клиентов, которые будут давать нам что-то взамен - обычно деньги. Наконец, проект разделит эти деньги между нами, инвесторами и правительством.
Хорошо спланированный и управляемый проект получает лучшие ресурсы, которые может позволить его бюджет, и полагается на их качество. Программист, не имеющий достаточных навыков или знаний, является ненадежным ресурсом. Очевидно, что ни один проект не будет приобретать такой ресурс с самого начала. Однако эта слабость может проявиться в середине проекта.
Представьте, что вы строите дом и наняли сантехника для установки системы канализации. Когда пришло время установить оборудование, он говорит вам, что никогда не работал с ним и не знает, как его установить. Это был риск, и он произошел. Хороший менеджер проекта всегда имеет запасной план или даже несколько из них. Очевидно, что лучшим вариантом было бы нанять другого сантехника. Худший вариант - обучать первоначального на месте.
Подождите, почему это так очевидно? Сантехник - отличный парень. Да, он не знает, как работать с этим оборудованием, но это не означает, что мы должны немедленно его уволить. Давайте заплатим за его обучение, отправим его на курсы, купим ему книги, позволим ему потренироваться с оборудованием некоторое время, и затем он сможет установить его в нашем доме. Отличный план, не так ли? Сантехник будет доволен.
Но проект - нет.
Цель проекта - построить дом, а не обучать сантехника. У проекта даже нет средств для обучения этого проклятого сантехника! Если мы обучим и научим всех наших сотрудников, мы никогда не построим дом. Мы здесь не ведем учебное заведение. Мы строим дом!
Во время работы над программным проектом хороший менеджер проекта имеет план управления персоналом, который описывает, как будут набираться, проверяться, применяться и увольняться навыки. Такой план может включать в себя обучение, но оно должно быть минимальным количеством - в основном потому, что сантехник, обученный нами, стоит намного дороже, чем тот, кто обучен кем-то другим, но делает абсолютно то же самое или даже хуже. Таким образом, умный менеджер проекта приобретает участников проекта, которые уже способны выполнять свои обязанности, и прибегает к обучению только в исключительных случаях.
Теперь логичный вопрос: что должны делать мы, как программисты? Мы хотим учиться, и мы не хотим тратить свои деньги на это. Мы не хотим сидеть дома несколько лет, изучая все возможные технологии, прежде чем выйти на рынок труда как эксперты, готовые быть нанятыми. Мы хотим учиться на работе. Мы в основном хотим использовать бюджеты проектов для наших собственных образовательных потребностей. Более того, умный программист уходит из каждого проекта с новыми знаниями, навыками и технологиями в своем портфолио.
Однако, если вы заставляете ваши проекты тратить свои деньги на ваше образование, это воровство. И хороший менеджер проекта должен остановить вас, сказав “Это не школа!”.
Какое же решение?
Я считаю, что в программном бизнесе есть только один обходной путь - винить проект в вашей собственной несостоятельности в образовании, навыках или информации. Я говорю абсолютно серьезно. Давайте обсудим несколько практических ситуаций.
Допустим, у вас есть модуль, с которым нужно работать, и он должен быть написан на Python. У вас нет опыта работы с Python, вы Java-разработчик. Кто виноват в этом случае? Вы можете считать это своей проблемой и попросить своего менеджера проекта научить вас, но он должен скзать, что он не ведет школу, и избавиться от вас. Это плохой сценарий для обоих. Вместо этого вините проектного менеджера. Он вас нанял. Он поставил вас в такую ситуацию. Он спланировал все проектные действия, поэтому, скорее всего, он знает, что делает. Это означает, что документация проекта должна быть достаточно подробной для того, чтобы Java-разработчик мог создать этот модуль на Python. Однако она н
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:07
