Бесценный опыт — опыт, за который никто не заплатит

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

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

Сразу оговорюсь, что это будут лично мои выводы, с которыми многие могут быть и не согласны. Буду признателен за конструктивные и познавательные комментарии и описания фрагментов вашего опыта. Не хотелось бы попыток «священных войн» в комментариях. Помните объявления о работе в 90-х с фразой «Не Гербалайф»? Аналогично — «Не холивар».

В статье затрону три темы:

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

Эти части имеют слабую связь. Как-то получилось, что любовь к слабым связям в разработке программного обеспечения просочились и в работу над данным материалом.

Четкой идеологической линии «Делай так и будет тебе счастье» нет. Основная мысль, которую я хотел вложить в материал — не стоит что-то идеализировать.

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

Итак, некоротко и местами несерьезно о серьезном…

Взгляд на код и разработку

С середины второго курса я переключился на C++, который стал моим основным языком программирования. Да, и это я говорил о том, что не стоит ничего идеализировать?.. Были «шалости» с иными языками программирования, но все ж они не отвлекли меня от C++. Так что повествование иногда может иметь некоторый привкус C++, что не мешает рассматривать написанное ниже в свете иных языков программирования, к тому же не только о программировании пойдет речь.

Идеального кода нет

Идеальный код — это как сферический конь в вакууме. К такому выводу приходишь не сразу. Хотя странно, люди грамотные, начитанные умными книжками, очень здраво рассуждающие в обсуждениях принимаемых решений и за обедом, а кода идеального нет. Вследствие чего и появляются статьи типа «WTF?». Да, можно оправдаться и жесткими сроками разработки, и неточностями постановки задач, и часто меняющимися требованиями, но…

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

Попробую привести пару примеров из проектов, в которых когда-то работал и которые можно отнести к не рассматриваемым в рамках сказанного выше.

В одной из контор мы поддерживали и немного развивали проект, который, как нам нам казалось, был написан начинающими студентами и как-то вышел на рынок, а потом только распухал. Почему мы так решили? Просматривался такой подход во многом, как «Мы сегодня на лекции проходили вот это. Нужно это или нет, мы все равно его применили в проекте, попробуем пройденное.» Это можно было заметить по некоторым фрагментам кода. Опишу в терминах С++. В классе, где и так все поля нормально переносили копирование объекта, был реализован конструктор копирования и оператор присвоения. Такого кода было много, его просто выпиливали кусками, а система продолжала работать, что закономерно…

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

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

Нет, конечно же, вы пишете идеальный код, а вот все остальные…

Как бы изящно не был написан код, он не идеален. Можно гнаться за упрощением и гнобить каждого за некоторые его «гениальные заделки на будущее». Можно, наоборот, увлекаться паттернами и заворачивать пятьдесят вторую фабрику в сорок восьмой Builder, и бегать по всему этому при помощи визиторов через нагроможденные мосты и адаптеры, поверх отшлифовать еще и несколькими фасадами. Можно «материться» сильными конструкциями языка (что, например, позволяет с легкостью сделать такое средство C++ как шаблоны). Но ни один из подходов не идеален.

Упрощение дает скорый старт и быстрое получение первых результатов, но велика вероятность со временем скатиться к «пластилиновой архитектуре».

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

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

На Хабре уже было высказано мнение, что система должна пройти три стадии развития:

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

Отношение к коду у разработчиков разное, особенно не к своему.

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

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

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

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

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

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

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

Код бывает идеальным? Нет не бывает! Бывает хорошего качества, с которым можно относительно комфортно работать многим разработчикам. Это, как правило, сторонние библиотеки или собственные корпоративные библиотеки общего использования. Они могут иметь неплохую репутацию, внешне иметь хорошие эксплуатационные характеристики, но внутри может быть не все так просто или качественно.

Так как я все же к C++ больше всего тяготею, то к примеру возьму в рассмотрение такую неоднозначно воспринимаемую библиотеку как boost. Да, ее часто называют полигоном для испытаний, из которого иногда что-то просачивается в стандарт языка, а остальное сильно упрощает жизнь.

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

В большинстве же boost воспринимается гораздо положительнее. Вы читали код этой библиотеки? А теперь попробуйте в таком же ключе написать код в своей команде и отправить его на ревью нескольким людям… Вполне можете получить кучу комментариев, которые будут настоятельно рекомендовать избавиться от всего этого странного кода и написать в более простой форме. А теперь та же ситуация, но вы архитектор, ведущий разработчик или просто человек с уже большим авторитетом в команде — все пройдет гладко — это можно считать примером того, что «качество кода» может зависеть от положения в иерархии сотрудников.

Велосипедисты и библиотекари.

Пара утверждений для начала:

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

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

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

Это лечится. Можно писать кучу всего своего до тех пор пока не приходит «корпоративка», когда есть куча сложных задач более высокого уровня, нежели написание собственных полезностей. Тут то в ход идут как библиотеки, разработанные уже кем-то, так и всевозможный сторонний код приемлемого качества для использования в решении той или иной задачи.

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

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

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

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

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

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

Занавес...

Все бы не плохо. Лень — двигатель прогресса. И это аксиома. Но кто же пишет все это, что можно натащить в проект? Может быть велосипедисты? Или такой код появляется от непорочного зачатия между мозгом с клавиатурой?

Гете высказывал мнение о том, что все уже давно открыто, нужно не бояться переоткрыть это.

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

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

В целом, от сторонних библиотек и прочего стороннего кода отказываться нельзя. Без этого просто можно погрязнуть в построении своих вспомогательных библиотек и не решить в заданный временной интервал основную задачу. Я всегда считал (и когда была возможность это реализовывал), что библиотека должна быть включена в проект, как минимум, если процент ее использования весьма велик. Не стоит тянуть в проект Qt только потому, что вам нравится QString и еще несколько классов. Вы не встречали проектов, в которых большие библиотеки притянуты в проект только из-за использования их очень малой части и только по причине трепетного отношения к ним некоторых разработчиков?

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

Использование «сильных» конструкций языка программирования и код дизайнерских изысков.

Русская речь без мата что борщ без томата.

Каждый язык программирования может иметь как базовый набор конструкций, так и расширенный, предназначенный для более тонкого использования и решения более сложных задач минимальными средствами. Стоит или не стоит их использовать? Я склонен к тому, что стоит обязательно! Но использование должно быть не избыточным. Попробую провести несколько аналогий с естественным языком, в частности с русским.

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

Можно естественный язык использовать просто, например, говорить только простыми предложениями. Согласитесь, человек говорящий только простыми предложениями выглядит весьма странно (речь идет о носителе языка, а не о иностранце, который осваивает чужой для него язык). Тогда почему в программировании есть адепты только «простых предложений»? Этот вопрос можно считать риторическим. А теперь предположим, что человек использует сложные предложения, но без всяческих вводных слов, причастных и деепричастных оборотов и прочего, скажу ближе к лексике разработчиков, «синтаксического сахара». Этого уже более чем достаточно для нормального ведения беседы. На этом многие разработчики и останавливаются в проекции на язык программирования. Средние конструкции языка, без сильных сторон и архитектурных изысканий, код как бы прост, но его много, порой очень много. Подобный подход один из самых распространенных. А теперь, как пример, можно рассмотреть естественную речь с использованием всего «синтаксического сахара». Такая речь дает максимум передачи краски при описании чего-либо, но если сильно этим увлечься, уже будет затруднено понимание такого повествования. Такая речь может быть более компактна при описании чего-либо по отношению к речи, построенной по более простым правилам. Так и в программировании: если не заиграться языковыми сильными конструкциями и архитекторскими изысками, а использовать их на грани извлечения максимальной пользы и минимума риска потери смысла в коде проекта, то можно достичь кода, близкого к идеальному.

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

В некоторых случаях можно слышать замечания в сторону эмигрантов о плохом знании языка страны, в которой они проживают. Но среди программистов наблюдается иногда парадоксальная ситуация: долгие годы, работая на одном и том же языке программирования, они используют весьма ограниченное подмножество этого языка и идеологий разработки на этом языке, и при этом с большим натиском могут отстаивать это, напирая на то, что отказ от «сахара» дает стабильность и много преимуществ в разработке и поддержке. Если брать пример из программирования, то несмотря на развитие такого языка, как C++ и библиотек с ним связанных, есть некоторый пласт, хранящий идеологию и стилистику такого инструмента своего времени, как MFC. Можно еще нередко встретить MFC-like style адептов. Это можно сравнить с эмиграцией, не стремящейся к изучению языка страны проживания, и яро отстаивающей такое поведение.

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

CodeReview & UnitTests

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

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

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

Юнит тестирование как и проведение ревью может дать положительный эффект на разрабатываемый продукт, и так же как и ревью оно должно быть оправдано внедрено в проект.

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

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

Стиль кодирования. Корпоративный стиль кодирования.

Пусть безобразно, зато однообразно. Так любил повторить один сотрудник кафедры, на которой я когда-то учился, и у которого можно было разжиться ГОСТ'ами по оформлению всяческих работ.

На Хабре иногда встречались статьи на тему стандартов кодирования, но рассказывать, что это хорошо, а это плохо в отношении стиля кодирования — это все равно что печку порохом топить. Резонансный материал… Обсуждать стили кодирования — это огромное пространство для священных войн. Так можно посмотреть статью с предложением правил оформления кода, описания войн табов против пробелов.

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

В коммерческой разработке, по моему глубокому убеждению, стандарт кодирования не может как-то сам по себе зародиться и существовать на протяжении какого-то времени, в течении которого разработчики меняются. Стандарт кодирования должен иметь какую-то форму кроме устной (документ в любом виде) и должен внедряться в обязательном порядке соответствующим руководящим звеном, ответственным за это. В противном случае как такового единого стиля кодирования не будет! Или он будет в очень ограниченном круге разработчиков (вплоть до одного) и непродолжительное время. Команда, в которую иногда приходят новые разработчики и которую иногда покидают старые, не сможет поддерживать единый стиль оформления кода если он не зафиксирован и не ведется контроль за его соблюдением. Так же маловероятно, что команда просто так пойдет за кем-то с его оригинальным стилем, если только они например не Саттер и Александреску со своим трудом «Стандарты программирования на C++. 101 правило и рекомендация».

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

В начале своего карьерного пути я, например, был ярым фанатом «венгерки». Считал, что это нечто гениальнейшее в оформлении кода. Можно этому и причину найти — большая часть времени проводимая на тот момент за разработкой под Windows и с тогда еще популярной библиотекой MFC. Но достаточно быстро я расстался с этим идеалистическим взглядом, поменяв несколько компаний как работодателей, а соответственно и познакомившись с несколькими корпоративными стандартами кодирования. В определенный момент стиль перестал играть для меня роль, но если он не закреплен в компании документом, то почему бы не выбрать наиболее оптимальный для себя?.. Все равно даже между несколькими защитниками уже сложившегося исторически стиля в команде и передаваемого только в устной форме будут немалые различия.

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

Иногда посягнув на стиль кодирования программиста в малом, т.е. в рамках подпроекта или даже файла или группы файлов проекта, можно получить возмущения на тему того, что программист не против смены стилей кодирования в рамках смены места работы, но чтобы менять стилистику от файла к файлу, которые приходится редактировать, он не готов. Может это и приемлемо, если вы не ищете разработчика, в сфере деятельности которого будет по большей части поддержка нежели развитие продуктов.

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

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

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

Сколько бы всего не было внесено в корпоративный стандарт кодирования, наибольшее количество дискуссий вызывает именно именование переменных и прочих сущностей. Немного об этом я уже написал выше, хочу еще один момент прокомментировать: длинные имена или короткие давать переменным и прочим сущностям. Есть адепты длинного именования. «Чукча не читатель, чукча писатель». Моя позиция: имена должны быть короткими и емкими, при этом минимизировать или почти отказаться от сокращений и аббревиатур, а не содержать полную историю сущности и ее назначение в этом мире. У любителей длинных имен есть любимый аргумент: чтобы было понятнее другому читающему. Или еще аргумент — современные среды разработки очень сильно упрощают набор длинных имен и это не проблема назвать переменную максимально длинно со всем ее многоликим смыслом. Нет это не так!

Если вы не можете дать четкое и емкое название сущности и при этом максимально короткое имя, вы не понимаете сущности, которую должны запрограммировать.

Обоснование этой точки зрения можно посмотреть в книге «97 этюдов для архитекторов программных систем» (Нил Форд, Майкл Найгард, Билл де Ора). Длинные имена — плохое понимание требований и задачи в целом, и чем понятнее становятся требования и задача, тем короче и более емки становятся имена сущностей. Так же за собой замечал, что иногда даешь много нелепых и длинных имен, разрабатывая непонятно что, а с большим осознанием и погружением в проект, возвращаешься и проводишь рефакторинг, сущности при этом приобретают более короткие и понятные имена.

Немного о поиске работы на московском IT-рынке

К разработчику предъявляется много пожеланий: создание качественного кода, владение разными современными методиками разработки, лояльность к ревью кода (с любой стороны), непреодолимая любовь к юнит-тестированию, а так же много иных пожеланий. Компании нужен именно такой разработчик. Нет, не нужен…

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

В одной небольшой компании, в которой я работал в должности системного архитектора, на которую я пошел посмотрев на свое резюме и на требования открытой вакансии, и найдя в них какие-то пересечения. Заслал резюме, далее интервью и скорое предложение о работе. Пересечений в резюме и в описании вакансии было немало, но были и пробелы, которые как оказалось в последующем и не нужны. Может показаться, что нужно было срочно найти хоть какого-то человека более или менее вменяемого и первого, кто подошел взяли. Проблема была именно в непонимании того, что надо и халатном отношении в составлении требований к кандидату. Это прояснилось немногим позднее, когда появилась необходимость в расширении штата, и уже мне принесли формируемое объявление о вакансии разработчика, которое не отличалось ничем от того, на которое откликнулся когда-то я, чтобы я из него вычеркнул все ненужное: навыки, которые компании сейчас не нужны, вряд ли понадобятся и никогда не были ранее хоть как-то применены в компании, и которые сильно могли увеличить стоимость разыскиваемого разработчика. Выкинув весь хлам из вакансии, мы увеличили поток соискателей, которых не отпугнуло все, что ранее было написано. А также поток соискателей увеличился за счет тех, кто более тщательно искал пересечения своего резюме с описанием вакансии. К сожалению, такие примеры не единичны и не только в малых компаниях.

Можно сказать, что изначально в требования закладывают как можно больше, а из пришедших на интервью разбирают по навыкам каждого на разные позиции. Но в таком случае открывайте несколько более четко описанных вакансий, уменьшится количество ненужной работы кадровых сотрудников, людей, проводящих техническое интервью, кроме того будет более оптимально использовано время соискателей. Да, в Москве пока рынок соискателя, и с этим так же приходится считаться. Меня берут сомнения в политике привлечения трудовых эмигрантов в эту область в обозримом будущем. К тому же дан очень хороший ответ в статье «Узбеки и IT».

Очень нередки несоответствия названий должностей и реально исполняемой работы. Попробую развить эту тему.

Иногда еще на первых этапах общения с hr-менеджером можно услышать фразу о грейдах в компании типа: «У нас все разработчики. У нас все равны.». Чуть позднее проясняется, что это не совсем так. Есть и более «равные». В этом может крыться и иная проблема: да, вроде как и все разработчики, но их компенсации рабочего времени отличаются друг от друга, они играют разные роли в проектах. К тому же если компания может себе позволить купить более опытного сотрудника и посадить его за работу на несколько позиций ниже его квалификации, отдача может стать минимальной. Кроме материальной мотивации, еще с ростом квалификации должна быть мотивация уровнем задач. Забивать микроскопом (купленным на мажорские деньги) гвозди в оконную раму не стоит; неудобно, микроскоп ломается, а расколотив вдребезги стекло еще и появляется много претензий к этому странному устройству, которое было взято вместо молотка соответствующего веса. Инструмент должен быть по задаче. И если компания наняла ведущего разработчика, архитектора, эксперта, переплатив ему процентов двадцать от среднерыночного, и новый работник был посажен за «клепание формочек», работник будет не мотивирован, работать посредственно и сбежит при первом же более интересном для него предложении.

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

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

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

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

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

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

Техническое интервью

На тему того, кто и как проходил интервью в той или иной компании найти на Хабре статью не составит ни малейшего труда. Я в этом так же был уличен в прошлом году. У меня было некоторое мнение на тему того, что хорошо, а что плохо, которое я описал в той статье; оно немного изменилось в последнее время.

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

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

Характер интервью очень сильно зависит от того является ли IT основным бизнесом компании или нет. Если IT — это основной бизнес компании, то в ней всегда есть потребность в разработчиках всех мастей, менеджерах проектов, сотрудниках отдела качества и т.д. В такой компании всегда есть необходимость в новых сотрудниках, это как дров в печку подкинуть. Разработчики приходят с горящими глазами, через некоторое время часть их перегорает и как дым улетучивается в другие компании. Можно заключать договоренности о непереманивании сотрудников, но если на рынке спрос на разработчика превышает предложение и зарплата hr-менеджера сильно зависит от количества закрытых вакансий, то возникает сомнение в том, что будет сделано максимально все, чтоб не переманивать сотрудника, да и не совсем законны такие договоренности. Были коллеги, которые поработали почти во всех компаниях, о которых речь шла в приведенной статье.

В компаниях, где IT является основой бизнеса, интервью уже по большей части поставлено на поток. Все это может проходить по примерно одинаковой схеме: небольшая беседа с кадровым работником, техническое интервью, проводимое несколькими группами людей, каждая из которых будет спрашивать очень узкую часть (одни задавать вопросы о языке программирования, другие о каких-то технологиях, подходах и методиках, третьи будут развлекать вас и себя всякими головоломками — ну как на госэкзамене, только без зачетки), после чего может следовать небольшая беседа с руководством. На этом интервью закончено и в течении какого-то времени должен быть прислан ответ, положительный или отрицательный. Как правило ответ присылается или можно еще при общении с кадровым работником уточнить, что вам в любом случае будет прислан ответ. По моему мнению — это более уважительная стратегия, чем просто умолчать при отрицательном результате, и если соискатель через достаточно большое время окажется интересен, с ним связаться. Давайте ответы в рамках оговоренных сроков. Это создает более положительное впечатление о компании, даже если отклик отрицателен. В случае внезапно возникшего желания у компании продолжить диалог с соискателем, он возможно будет более расположен, чем при условии, что на его потраченное время ему не дали никакого ответа.

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

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

Как ни странно, но у меня сложилось странное впечатление, что не смотря на большую вовлеченность в разработку и повседневные ее проблемы, интервью в IT компаниях не блещут оригинальностью и качественным отбором кандидатов даже при изнуряющих многочасовых технических интервью (а иногда и не в один этап). Более приближенными к будущей реальности могут быть интервью в компаниях, где IT является вспомогательной частью основного бизнеса. Здесь люди проводящие интервью не столь изощренные в вопросах, так как поиск сотрудника гораздо более редкий процесс в такой организации. И, как правило, вопросы могут быть из разряда того с чем пришлось столкнуться в своей практике или вопросы, над которыми на данный момент ведется работа в отделе исследований и разработки. Конечно не исключен и абсурд на интервью не зависимо от рода ее деятельности, связанный с некоторыми желаниями «сбить» желаемую заработную плату или просто немного заняться самоутверждением. Это грустные и неинтересные случаи, которые не стоит рассматривать. Такие интервью лучше всего самому быстро свести к концу и покинуть компанию. В то время как компания может быть вполне интересна и в иной раз при общении с другой ее командой все будет гораздо лучше, и вы получите отличное предложение о работе.

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

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

Каким бы ни было интервью: длительным и изнуряющим, при котором делается попытка разведать все залежи знаний у соискателя или просто беседа про предыдущий опыт с акцентами на интересующих навыках — все это не даст полноты картины. Четкое представление о кандидате даст испытательный срок и при условии помещения сотрудника в реальные проекты, а не в проекты «для разгонки» на испытательном сроке. Так же желательна максимальная заинтересованность в передаче опыта новому сотруднику, чтобы он стал эффективным, и после не заниматься «мелким попечительством» (решением задач подчиненного, потому что кажется, что самому их решить проще в данный момент).

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

Деньги

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

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

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

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

О проектах и менеджменте

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

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

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

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

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

Проблема прямых указаний

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

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

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

Казалось бы все хорошо: менеджмент может давать поручительства исполнителям, исполнители напрямую могут взаимодействовать с разными уровнями руководства. Идиллия… Анархия!

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

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

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

А если говорить об описанной проблеме, то не всегда бизнес близок по своей компетенции к сотрудникам, исполняющим конкретные задачи. Хорошим примером может послужить попытка обоснования сроков выполнения простой задачи в статье «Как две недели?!». Так же в подобных случаях есть проблема того, что разработчик будет принимать к реализации задачу, поставленную тем уровнем менеджмента, от которого в большей степени будет зависеть его заработная плата. При грамотном подходе такие ситуации исключены, при неграмотном — нет, и проблемы проекта не за горами.

Взгляд на проекты с разных ракурсов

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

Читая аналогичную литературу формируются некоторые паттерны, которые как бы давно известны и понятны, но теперь их только можно более четко назвать своими именами. Это как прочтение книги типа GoF для разработчика. Разработчик и так давно пользовался, например, фабриками классов, но теперь он узнал, что это ж, блин, паттерн, а не просто его сущность, которую он из проекта в проект плодил не всегда называя его в общении с коллегами именно фабрикой классов.

Так что же предлагается в светлых взглядах? Перевернуть пирамиду управления!

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

Если попробовать сравнить с неким отделом, деятельность которого заключается в работе с клиентами, то начало диалога клиента с любым сотрудником такого отдела может быть начато сотрудником, например с фразы: «Чем я могу помочь?». Перенаправить клиента к компетентному сотруднику, а при его отсутствии в данный момент, максимально его заменить. Не ограничиваться фразами типа: «Это не моя работа. Обратитесь в другое окошко».

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

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

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

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

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

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

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

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

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

Еще можно приводить некоторые аспекты высокоэффективной организации во взглядах с позиции «добра». Но, поработав как в больших, так и в малых компаниях и даже побывав в стартапах (очень и очень своеобразных), я ни разу не встречал, к сожалению, действительно высокоэффективной организации. Может мне не везет, я живу не в том городе, не в той стране, выбираю не те компании? Вопрос риторический. Хотя в прочтенной книге о светлом высокоэффективном управлении приводилось немало примеров крупных компаний с положительной динамикой внедрения описанных принципов. Где-то были некоторые элементы стремления к высокой эффективности без серного пчеловодства, но в целом позитивного управления не так много. В больших компаниях «крякание» встречается чаще. Малые иногда так же могут встать на путь большевиков и плодить декреты за декретами, т.е. в малой организации наворотить весь груз больших организаций, кучу департаментов (в каждом из которых будет по два человека: исполнитель и его руководитель), множество менеджеров и небольшой процент исполнителей. Работал я в одной небольшой компании, где управленцев было на две трети больше исполнителей, которые и должны были «делать продукт», ушел, много абсурда в таких компаниях, который все равно приведет к ее краху. Тут главное уйти как можно скорее, пока все проблемы компании не стали вашими финансовыми проблемами.

Если же посмотреть на достижение эффективности уже с темной стороны, которая описана в «Менеджере мафии», то тут совсем все по иному. Руководитель уже не должен особо суетиться. Степень его вовлеченности в процесс падает с продвижением его по карьерной лестнице вверх. В этом ключе утверждается, что самая сложная задача на вершине карьерной лестницы — это борьба со скукой. Если вы сменили не одну компанию как работодателя, то вполне могли наблюдать картину в одной из них, что чем выше руководитель, тем больше он слоняется по офису, читает что-то типа новостей в интернете, иногда прочитанным делится с коллегами примерно его уровня и лишь иногда принимает участие в обсуждении каких-то производственных задач и то по максимуму пытаясь от них увильнуть, переложив все на подчиненных. Это уже классическая пирамида в управлении. Желание движения к вершинам обусловлено вполне объяснимым желанием иметь больший достаток с минимумом собственных трудозатрат. В такой структуре по максимуму все перекладывается на плечи подчиненных, но за комфорт менеджера приходится и платить меньшей отдачей от подчиненных в виде приносимой прибыли. Не потому что они не хотят работать. У них просто может не быть всего необходимого в данный момент для решения поставленной задачи, а взаимодействие с менеджментом вносит временные задержки.

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

К найму сотрудников для менеджеров имеется вполне четкая рекомендация: подчиненных должен обязательно нанимать (сюда же можно отнести и проведение собеседования) именно его будущий непосредственный руководитель, а не члены его команды. Менеджер сам формирует свою команду и мнение подчиненных не берется в расчет. Так как нанимаемый сотрудник — это будущий исполнитель именно менеджера, а не угодный коллега другим членам команды. К счастью, таких ситуаций при поиске работы в чистом виде не так много встречается. Если говорить о разработке ПО, то будущего сотрудника как правило могут собеседовать его будущие коллеги и только на следующем этапе интервью уже будет диалог с менеджментом.

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

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

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

Проводя параллель между решением задач в проектах и усилением сигнала в том же приемнике можно сказать, что, например, мозговой штурм аналогичен ПОС, а контроль за исполнением найденного решения и контроль качества продукта сравним с ООС.

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

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

Так вот, когда мы предложили бизнесу наше легко достижимое решение нашего же «очень» логичного инструмента, бизнес представитель как-то странно посмотрел на нас и выдал: «Как вам это в голову пришло!» с дальнейшим разъяснением того, что таких ситуаций в данной области не может сложиться в принципе.

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

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

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

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

Особенности, оставшиеся за кадром

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

Интересный пример из моей практики, как раз из той компании, в которую я пошел «за рублем».

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

Менеджмент, боясь сорвать сроки выпуска продукта, набрал некоторый буфер разработчиков, который по максимуму использовался только в пиковые моменты проблем в продукте. Было ли это обосновано с точки зрения управления рисками или просто страх завалить проект менеджером, сказать не могу.

По рискам так же можно посмотреть такой источник как «Вальсируя с медведями» Том ДеМарко. По прочтению которого, можно понять многие абсурдные вещи менеджмента в свете управления рисками.

Заключение

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

За рамками статьи осталось еще много примеров и рассуждений. Например, о названии интерфейсов с именами в виде IIssue13162215 в крупных проектах больших компаний с обязательным ревью кода. Как они туда просочились с такими именами, сформированными из системы работы с дефектами. О проекте, в котором можно было найти все до единого паттерна из книги GoF, и в котором было очень не комфортно разработчику, так как для простого получения любого свойства сущности нежно было реализовать соответствующий интерфейс визитора. Так же в прошлом году я искал не спеша и местами дерзко работу, которая должна была меня удовлетворить по максимуму критериев. Из этого поиска хватило материала на мою статью приведенную выше и еще многое осталось «за кадром». Есть так же неописанные в этой статье примеры из проектов, в которых я был как рядовым их исполнителем, так и с возможностью покрутить за баранку управления. Все это именно тот самый бесценный опыт, за который в чистом виде никто не заплатит. При продаже основных навыков работодателю можно подливать к ним и этот самый бесценный опыт, и только в этом случае он приобретает уже вполне реальную цену.

На самом деле у любого сотрудника, который имеет хоть какой-то не нулевой опыт, уже есть примеры того самого бесценного опыта, которым он так же может поделиться заставив его «лечь на бумагу» «превратиться в цифру» (цифровое время; бумага неохотно, но сдает позиции), т.е. просто найти время и желание его изложить в печатной форме. С ростом количества пройденных проектов этот багаж сильно возрастает. Огромное количество этого самого «бесценного» дает участие в стартапах, так как в отличии от больших и малоповоротливых компаний, в стартапах многое делается «на грани», приводя к странным и интересным результатам. О стартапах так же много написано на просторах того же Хабра. Как пример мне недавно попалась статья с описанием типажей в стартапах. К сожалению, в нашем постсоветском пространстве слово «стартап» небезосновательно набило многим оскомину и если вы были участником стартапа, его идеологом или просто помышляете о нем, рекомендую обязательно посмотреть видеовыступление Ашманова (к моему большому сожалению, ссылку мне не удалось найти, утерял, это выступление было примерно пару лет назад, был пост на Хабре; если кто-то найдет, поделитесь пожалуйста), в котором дана очень хорошая характеристика стартапам и многим сопутствующим моментам. Так же многие из IT-специалистов склонны к саморазвитию с изучением всевозможных источников, что и дает еще некоторое вливание все в ту же копилку этого самого казалось бы бесценного опыта.

В статье я максимально, насколько это было возможно, старался избегать привычных жаргонов, типа «таймсейверы», «таск неканселябельный» и так далее, которые с легкостью конструируются в IT-среде ее работниками из слов русского и английского языков. Такие выражения могут быть понятны в рамках команды или даже немного выходить за ее пределы, могут иногда в рамках команды упростить передачу информации между сотрудниками, но недопустимы, когда вы например из среды разработки внезапно попадаете на встречу с инвесторами или иными представителями бизнеса. Для них подобное может быть не понятно, а желание не ударить лицом в грязь не даст возможности переспросить и разъяснить смысл некоторых слов. Как результат — можно потерять некоторые финансовые потоки в проекте или компании. Так же при создании материала, не только для рамок некоторой команды, подобные жаргонизмы недопустимы, так как могут сделать материал недоступным. От чего и хотелось уйти при написании данной статьи. Времена, когда инвестор услышав несколько непонятных слов, подбирал отвисшую челюсть с пола от изумления и доставал чемоданчик денег на проект прошли.

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

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

Всем спасибо за внимание!

Автор: NYM

Источник