Действительно ли планирование столь полезно в программировании

В последнее время, разговоры о тайм-менеджменте, планировании и эффективном использовании времени можно услышать даже в самых неожиданных местах. Мало кого обошла эта волна трекеров привычек, приложений для составления распорядка дня или дедовских методов со всевозможной канцелярией и новенькими ароматными блокнотами. Прелестью таких экспериментов остается то, что они, в случае чего, могут быть легко отменены, но когда речь идет о работе, все не так просто. В прошлой статье на эту тему, мы, по большей части, затрагивали тему фриланса. А сейчас поговорим о программистах, которые работают в компаниях. Рассмотрим возможности, которые привнесла конкуренция между работодателями, упомянем о стрессе, сорванных дедлайнах и человеке с палкой.

Для составления хорошего плана тоже нужен план

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

— Я долгое время работал менеджером-управленцем и скажу так — планирование необходимо в любом случае, но оно должно иметь рамки. Расписывать каждый час — перебор.

Составить качественный план требует отдельного планирования. То есть, под его составление нужно выделять еще очень много времени, учитывать очень много ресурсов и аспектов. Зачастую, очень сложно составить на сто процентов выполнимую схему даже для себя. Все факторы учесть невозможно, поэтому применяется принцип допусков. Например: «Здесь я могу сделать за час или плюс-минус полчаса, а может быть и не за полчаса, а за пятнадцать минут или час». Регулируя эти допуски принимается более-менее жизнеспособный схему. Но четко-четко все спланировать и просчитать эти допуски — это еще целая отдельная наука. Компенсируются ли временные затраты на составление плана, выгодами от его реализации?

Время, когда над программистом стоял человек с палкой, уходит

То, что IT столь стремительно развивается, обеспечивает не только множество рабочих мест, но и благоприятную среду. Так, при большой конкуренции формируется совершенно другое отношение к специалистам и появляются очень заманчивые схемы сотрудничества. Частично именно поэтому многие люди идут на оффлайн или онлайн курсы по frontend.

— Есть компании, в которых ведется учет времени. Но сейчас от этого уже очень многие ушли. Потому что IT-специалисты ценятся, а за системы учета нужно очень хорошо платить, чтобы программисты оставались на таких галерах. Потому что под такой барабан много не погребешь.

Очень многие уже отказываются от этих систем, так как есть масса предложений, где гораздо проще и понятнее график работы и отношение к программисту. В том числе, были предложения, когда компания говорит: «У вас будет проект, но мы понимаем, что через два-три месяца программист вместо восьми часов уже работает четыре или шесть часов. Потому что он уже хорошо ориентируется в проекте, хорошо понимает структуру, бизнес-аналитику и ему нужно гораздо меньше времени, чтобы выполнять ту же работу, которую он выполнял до этого». Тут возникает момент, когда программист напрягается и думает: «А что же последует за этим?». А следует вот что: «Мы предлагаем взять еще один проект, за еще одну ставку», — шикарные условия. И именно предлагают, не навязывают. Таких компаний все больше и больше на рынке.

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

Неочевидно, но ты можешь просто сказать, что не успеваешь

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

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

А во-вторых, появляются софт-скиллы, вроде ответственности и способности выполнять свою работу в те или иные сроки. Или хотя бы оценивать их, даже если ты не успеваешь. Это, кстати, совсем неочевидная для многих вещь — ты можешь просто сказать, что не успеваешь. Это действительно так. Такое предупреждение не будет смягчать вину, ведь на программиста ее никто не вешает. Ситуации бывают разные.

Заказчики тоже, зачастую, никакие не драконы

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

— Программное обеспечение — это та область, где невозможно все предсказать, ведь взаимодействие компонентов часто бывает вообще не очевидным. Изначально казавшаяся простой задача, может потребовать много времени. Очень важно обсуждать данный момент (для этого проводятся ежедневные скрамы). Он должен быть понятен твоему руководителю — тимлиду или Project Manager, чтобы он мог обсудить ситуацию с клиентом.

Заказчики тоже, зачастую, никакие не драконы. Они тоже понимают ситуацию и могут сказать: «Ок, нам этот функционал не очень важен или не нужен в том объеме, в котором мы его изначально предполагали. Можем его сократить, раз это проблема». Но сам факт того, что вы не убиваетесь на работе по двенадцать часов для того, чтобы все было идеально, при этом даете обратную связь — рассказываете о проблемах и том, что вы с этим разбираетесь, дает возможность проекту двигаться вперед. С жестким ежедневным планированием, по моему, это не имеет связи.

Стресс, в итоге, всегда выливается во что-то

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

— Как по мне, любой план создает напряженность — тебе нужно спешить и успевать, а это стресс. А он, в итоге, всегда выливается во что-то. Соответственно, факторы, которые увеличивают стресс, приведут только к ухудшениям. Любые болезни нужно лечить, а лечение — это время и деньги. Ладно, если повезло, компания страхует. Но время-то она теряет ваше. В какой-то момент нужно проводить жесткую черту — здесь я работаю, а здесь отдыхаю, мне комфортно работать вот так, а не вот так.

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

Заметили ошибку? Выделите ее и нажмите Ctrl+Enter, чтобы сообщить нам.

31.05.2019
65
Автор: Ася Яскер