Занимаясь обучением, совершенствуя свои навыки и углубляя свои знания в предметной области, я не думала о том, как устроен процесс разработки с точки зрения рабочей единицы в команде разработчиков. Кому я подчиняюсь, кто дает мне задания, кто не должен мне давать поручения и кому отдавать на проверку, кто проверяет мои pull-request'ы? Все эти вопросы не возникают, когда ты сидишь дома, выполняешь учебные задачи, попивая чай и отвлекаясь на всякие домашние дела. Никто тебя не будет дергать по задачам, которые ты делал неделю назад, никто не будет тебя спрашивать, чем ты занимаешься и почему так долго, никто не будет тебе давать задачи, пока ты занят текущими. Одному прощу работать.
Однако будучи в компании и являясь частью большой команды, ты становишься частью механизма, который работает постоянно. Люди, работа которых зависит от твоей работы, будут тебя постоянно дергать и спрашивать. Ты будешь спрашивать у других и пытаться добиться ответа здесь и сейчас, потому что твоя работа стоит. Ты начинаешь нервничать, потому что пока ты ждешь, тебя уже ждут другие. И самое главное, когда работа ведется над сложным проектом, твои коллеги могу работать и ночью, и на утро у тебя может оказаться несколько задач которые тебе нужно решить, чтобы не задерживать остальных.
На начальных этапах человек, который может тебя спасти от неожиданностей со стороны других членов команды, это менеджер. Менеджер проекта должен мониторить, сколько задач у тебя есть на данный момент, следить, чтобы другие руководители или коллеги не грузили тебя другой работой. Конечно он тоже не будет ждать вечно, могут быт обозначены сроки.
Взаимодействие с руководителем и коллегами лучше ограничивать системой управления проектов (чаще встречала Jira), где отражены все текущие задачи и сроки их выполнения. Бывает, что обращаются менеджеры других проектов за информацией по задачам, которые были сделаны месяц назад и более, вроде как по дружбе, подсказать как это работает. Тут сразу нужно предупредить, что сначала надо поставить в известность твоего менеджера для того, чтобы он был в курсе, что два часа времени ты потратил на то, что помогал коллеге с другого проекта.
Конечно, когда под твоим руководством уже несколько других программистов, то зона ответственности резко возрастает, помимо своей работы надо скоординировать работу еще и других. Об этом написано много книг и советов, так как взаимодействие между людьми — это важный фактор развития не только проекта, но разработчиков этого проекта. Есть много факторов благоприятной атмосфера в команде, это уже из психологии :) Есть такая практика даже, как возрастной ценз на определенные должности в команде разработчиков.
Каждая компания достигает эффективности своими методами, но всегда необходимо четко понимать, что существует SLA (Service Level Agreement), который важно соблюдать, что есть внутренний учет времени программиста и важно научиться не только выполнять задачи, но всегда ориентироваться на поставленные сроки.
