От джуна до сеньора

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

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

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

К сожалению, рецепта идеального баланса обсуждений нет, и каждая компания спустя некоторое время приходит (или не приходит) к тому количеству разговоров, которое устраивает и руководство, и сотрудников. Для вас, как для профессионала, важно понимать, что ваша задача и приоритет на проекте – разработка качественного кода. И только вы можете знать, делают ли многочасовые разговоры ваш код лучше.

Тезисы

■ Мало обсуждений – плохо.

■ Много обсуждений – тоже плохо.

Задание

Если в компании проводятся регулярные митинги, попробуйте ответить честно: насколько полезны они для вас как для разработчика? Если вы чувствуете, что они полезны и вы получаете больше опыта, – прекрасно, я могу за вас только порадоваться. Если же вам кажется, что на этих обсуждениях вы лишь теряете время, поинтересуйтесь у руководства, нельзя ли реже принимать в них участие.

История из жизни

Я настолько не любил пустые ежедневные обсуждения, что это стало для меня одной из мотиваций, чтобы развиваться как разработчик. Я хотел получить возможность сказать «нет, мне некогда», однако это сыграло со мной злую шутку. Поднимаясь вверх по карьерной лестнице, ты становишься тем самым человеком, который и инициирует подобные обсуждения, и обязан на них присутствовать. Любви к пустым обсуждениям у меня, разумеется, не появилось, поэтому я стараюсь не отвлекать разработчиков, если только для этого нет по-настоящему веских причин.

Бюрократия

Как бы печально это ни звучало, но бюрократия на сегодняшний день – неотъемлемая часть мира IT. Она проникает в нашу индустрию потому, что руководству компаний нужна четкая структура и понимание продукта (с какой скоростью и с какими перспективами идет его разработка). Это благое желание, которое часто выливается в замедление или усложнение разработки.

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