Как управлять программистами?

Как управлять профессионалом?

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

Как управлять ленивой жопой?

Очень просто! Чем "ленивее" программист, тем меньше должна быть задача. Почему ленится человек? Потому что боится большой работы. Если ему кажется, что он "всё равно" не справится с задачей, то зачем напрягаться? А если ещё и задача из серии "принеси то, не знаю что, но чтобы вчера!", то тут уж совсем грусть-тоска. Профессионал за такие задачи пошлёт вас в пешее эротическое. Он не будет тратить время в пустую. А вот люди с меньшим опытом возьмутся за такую задачу и автоматом станут и ленивой жопой, и горе-программистом, а может и похуже. И получается, что постановка задачи во многом определяет успех её решения.

Если вы поставили задачу грамотно, то на 90% она уже выполнена. Оставшиеся 10% - клевать мозг исполнителю. Лучше делать это в начале рабочего дня, когда продумывается план на день. Потом после обеда и, конечно, перед уходом. Тут самое главное - не перегибать палку! Нужно просто спросить: "Всё хорошо? Вопросов нет? Задача движется?". Если будут вопросы, то они оперативно решатся, если затык в коде, его можно будет быстро купировать. В любом случае задача не умрёт из-за какой-нибудь глупости а-ля "ну я же не знал, а мне не сказали, и т.д." А через некоторое время выработается привычка работать в таком режиме, и клевать надо будет в разы меньше.

Типичные ошибки при управлении программистами

1. Быть самым умным. Каждый программист считает себя самым умным и крутым. И не важно, профессионал он или ленивая жопа. Не нужно с пеной у рта доказывать всем свою умность и крутость. Уважение программиста можно завоевать или мудростью, или умением решать задачи лучше чем он. Мудрость обычно заключается в умении ставить задачи, рассказать анекдот и вовремя свалить. Крутость же можно доказать только кодом. Взять задачу и решить её быстрее, лучше, эффективней, чем остальные. На словах вы ничего и никому не докажите. Каждый всё равно будет думать: "Но я-то точно знаю, кто тут самый умный! Хе-хе."
2. Мешать работе. Если вы поставили задачу, уйдите и не мешайте. Не надо рассказывать о космических кораблях, которые избороздят большой театр, как только задача будет готова. Не надо проедать плешь лекциями о важности и нужности задачи по три часа. Это лишняя информация, которая отвлекает от сути и занимает разум программиста. Поставил задачу, уточнил, всё ли понятно и ускакал за тридевять земель. Во время обеда уточнил, всё ли хорошо, и улетучился, как парниковый газ. Вечером выпал с осадками, проконтролировал задачи и отпустил с миром.
3. Решать задачи за программиста. Очень часто руководители говорят, что задача пятиминутная, делов-то на пару строк. За пять минут можно только сломать. Лично я могу сломать за пять минут очень много. Мой многолетний опыт и глубокие знания предметной области позволяют за пару минут наломать столько, что хрен вы потом восстановите и за месяц. Поэтому не надо говорить программисту, как он может решить эту задачу за N минут. Это его работа - думать, как решать задачи.
4. Требовать невозможное. Нельзя сегодня сделать отчёт вчера. Как бы ни был нужен отчёт вчера, если задачу поставили сегодня, то вчера вы отчёт уже точно не получите. Планируйте заранее, какие задачи нужны будут в обозримом будущем с поправкой на человеческие возможности программиста. Ну, а если вы запланировали, будьте добры, контролировать выполнение.
5. Считать рабочие минуты. Программист решает задачи даже, когда спит. Время, когда он стучит по клавиатуре, это капля в море. Чтобы что-то напечатать, надо что-то придумать. Программист должен решать задачи, а не сидеть восемь часов уткнувшись в монитор. Контролируйте задачи, а не минуты.

Работе время, херне час

Из своей практики могу сказать, что эффективность программиста сильно падает через 5-6 часов работы. И лучше на это ориентироваться. Уставший программист - враг проекта. Он делает много ошибок, которые в конечном счёте превращаются в убытки компании. Поэтому лучше планировать рабочий день так, чтобы задачи заканчивались примерно за час до конца рабочего дня. Этот час нужен, чтобы настроиться на следующий рабочий день, эмоционально разгрузиться, почитать свой код или тематическую литературу, пообщаться с коллегами. И на следующий день прийти с хорошим настроем на работу. Ещё он нужен ещё и как подушка безопасности, на тот случай, если что-то не успел или что-то сломалось. Лучше потратить час херни на херню, чем отрезать час от задачи.

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

Злоключение

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

Старайтесь не совершать типичных ошибок, ставьте хорошие задачи, не забывайте про практику биты и весла и всё будет хорошо.