В случае если в вашей команде нет человека, отвечающего за решения по архитектуре и развитию проекта, вам будет очень-очень непросто. Любой проект проходит стадии развития. Он растет, эволюционирует, крепнет. И он будет изменяться, подстраиваясь под задачи, которые должен выполнять, или под требования клиентов. Иногда он будет меняться кардинально, а это требует смелости и умения смотреть в будущее (у вашего архитектора есть хрустальный шар, точно говорю).
Разработчики достаточно амбициозны, и если у вас нет сотрудника, принимающего важные решения по развитию проекта, кто-нибудь из ваших коллег попытается занять это место. Это может быть большой удачей, в случае если человек обладает достаточным опытом и изрядным запасом интуиции. И это же может стать провалом, если сотрудник просто хочет признания, не обладая при этом знаниями и способностью выбрать правильный курс.
Если в какой-то момент карьеры именно вы окажетесь тем, кто принимает ключевые решения, я заранее поздравляю вас. Поздравляю с тем, что отныне каждый ваш выбор будет делить людей на две или больше групп. Часть из них будет согласна с вашим решением, а часть – сопротивляться ему так, будто вы пытаетесь поджечь их дома. Это нормально, опирайтесь только на объективные критерии выбора. Да, когда вы объясняете, что необходимо сделать, старайтесь находить правильную аргументацию и слова. И не нужно угождать всем, ваша задача – сделать проект сильнее и лучше.
Тезисы
■ Каждый проект – это совокупность больших и маленьких решений.
■ Человек, не обладающий достаточным опытом принятия решений, так же плох для проекта, как и отсутствие человека, принимающего решения.
■ Если решения принимаете вы, будьте готовы столкнуться с сопротивлением.
Задание
Если в вашей команде есть человек, отвечающий за принятие ключевых решений по развитию проекта, – прекрасно. Попробуйте анализировать его подходы, его рассуждения при принятии решений. Находясь на позиции наблюдателя, вы сможете оценить, были ли принятые решения верны в долгосрочной перспективе. Поставьте себя на его место: будет ли вам интересно принимать такие весомые решения? Готовы ли вы нести за них ответственность?
История из жизни
Моя история, связанная с этой темой, довольно печальна. Я был middle-разработчиком и работал с техническим руководителем, который имел очень приблизительное представление о разработке и технических решениях. Собственно, он был из тех специалистов, которые окончили платные курсы и по случайности получили должность, позволявшую им принимать ключевые решения по развитию продукта. Я не обладал достаточной уверенностью или опытом, чтобы оспаривать его решения, но видел, что на дальней дистанции с ними возникнут большие сложности. В итоге я просто отмалчивался и продолжал им следовать, наблюдая, как проекту становится все хуже. Молча смотреть, как продукт, в который ты вкладываешь так много себя, страдает и теряет аудиторию – болезненный опыт, повторения которого я бы не хотел.
Обсуждения
Если бы мы стали делить разработчиков на типы (а глупее занятия не придумать), то можно было бы сказать, что они делятся на тех, кому нравится обсуждать свою работу, и тех, кто предпочитает работать молча. Принадлежность к одному из этих типов не делает разработчика хуже или лучше, это всего лишь стороны характера, особенности личности. Кому-то по душе обсуждать все нюансы своей задачи с коллегами, кому-то удобнее разобраться со всеми вопросами один на один.
Обсуждение проекта в коллективе – очень важная часть рабочего процесса. Но ровно до тех пор, пока оно не начинает мешать работе над проектом. К сожалению, соблюдение баланса в обсуждении задач и рабочих процессов – дело очень-очень непростое. И чем больше людей вовлечено в обсуждение, тем сложнее оно становится. А если в команде нет человека, который может принять окончательное решение, процесс становится бесконечным.
Поверхностное или слишком сжатое обсуждение в рабочем процессе грозит тем, что разработчики не смогут увидеть общую картину. Задачи будут выполняться не полностью, с ошибками, без учета всех требований, а иногда абсолютно некорректно, просто потому что у разработчика нет полного понимания того, что он делает. Замечательно, если разработчики в вашей команде способны на самостоятельный анализ, оценку рисков и четкое понимание требований без долгих разговоров о них.
Другая сторона медали – чрезмерное обсуждение, разговоры по делу и без, многочасовые митинги и совещания с короткими перерывами на разработку. Такая проблема свойственна большим компаниям, где, согласно корпоративной этике, хороший разработчик – тот, кто присутствует на ежедневных митингах и с восторгом рассказывает о том, что он уже сделал и чем планирует заняться дальше. Поймите меня правильно: я не считаю, что совещания с коллегами – это плохо. Обсуждение работы над проектом – прекрасная вещь, но только если оно не ворует ваше рабочее время.
Иногда способы, которыми руководство и менеджеры решают проблему контроля за разработкой, буквально парализуют компанию. В попытке получить больше информации о том, чем занимаются сотрудники, вас будут раз за разом собирать в залах и комнатках, где нужно будет рассказывать, что и как вы делаете. Если вы работаете над большим продуктом, то, разумеется, такие встречи необходимы. Отделы должны понимать свои задачи, контактировать и узнавать друг друга в лицо: это упрощает коммуникацию внутри компании. Но если вы понимаете, что из восьми часов рабочего времени потратили пять на разнообразных обсуждениях, значит, в вашей компании что-то идет не так.
К сожалению, рецепта идеального баланса обсуждений нет, и каждая компания спустя некоторое время приходит (или не приходит) к тому количеству разговоров, которое устраивает и руководство, и сотрудников. Для вас, как для профессионала, важно понимать, что ваша задача и приоритет на проекте – разработка качественного кода. И только вы можете знать, делают ли многочасовые разговоры ваш код лучше.
Тезисы
■ Мало обсуждений – плохо.