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