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

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

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

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


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

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

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

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

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

В комментариях велели картинку для привлечения внимания вставить. Исполняю.



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

— Ну что, как дела?
— Нормально. – отвечаю я.
Как же, нормально. Нормально было, пока ты не приперся. Ты всегда выбираешь очень неудачный момент. За это я тебя, сволочь, и ненавижу.
— Как статья? – с ехидством спросил ты.
— Нормально. – не хочу, если честно, в подробности вдаваться.
— Точно нормально?
— Точно.
— А чего тогда у нее такой рейтинг низкий?
— Не пошла.
— Опять?
— Опять.
— Так может, того?
— Чего того?
— Ну, сам знаешь…
— Нет.
Достаю сигарету, закуриваю. Собака рыщет в траве, чего-то ищет. Никогда не понимал, чего она там находит. Иногда в траве валяются дохлые птицы, но сейчас трава редкая, и на полянке точно ничего нет. За чистотой я слежу.
— Почему нет-то? Может, будешь честным с собой? – продолжаешь ты с серьезным лицом. – Статьи твои – говно, и никому не нужны. Это – реальность. Тебя все ненавидят. Ты просто графоман. Признай это.

Случалось ли вам видеть автоматизацию производственного предприятия, выполненную за 2 месяца? Или, может быть, доводилось делать такую автоматизацию? Я уверен, таких примеров много. У меня тоже есть – кидаю в копилку.

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

Мне этот опыт, честно говоря, не пригодился. Я больше никогда в жизни не делал автоматизацию так быстро. Стас – тоже не делал. Ну всё, погнали.

Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.

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

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

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

Матрица Эйзенхауэра – очень известный метод определения приоритетов. Например, в знаменитой книге Стивена Кови «Семь навыков высокоэффективных людей» матрице посвящена целая глава.

Матрица – это инструмент расстановки приоритетов задач. Придумал ее, говорят, 34-й президент США Дуайт Эйзенхауэр. Определять приоритеты с помощью матрицы просто и эффективно.

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



Любая задача, которую надо сделать, попадает в один из четырех квадрантов матрицы. Выполнять следует в порядке сверху вниз, слева направо. Сначала – срочные и важные, потом – срочные и не важные, дальше не срочные и важные, и, наконец, не срочные и не важные.

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

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

Во всем виноват сука-программист. Всё из-за него. Сейчас я тебе все расскажу.

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

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

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

— Так… Давай еще раз, в чем смысл?

Сергей не спеша, с наслаждением затянулся сигаретным дымом и с озорной улыбкой глянул на Марину.

— Эх, жалко, тебя не можем с собой взять – они уже запомнили, что ты директор по качеству. Эксперимент не удастся.

— Да какой эксперимент-то?

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

— А этот… Друг твой зачем?

— Толян-то? Кстати, Толян, еще раз спасибо, что так быстро приехал. Проблем на работе не будет?

— Нет. – буркнул парень в очках и с синеватой щетиной на лице. – Я фрилансер, у меня нет работы. В отличие от тебя.

— Позволь представить, Марина. Это Толян. Мы с ним вместе учились и проходили практику на заводе. Занимались, как раз, качеством продукции. Но я – так, по верхам. А Толян шарит.

— Приятно познакомиться. – кивнула Марина. – Что дальше, Сергей?

— Щас докурим и пойдем в цех. А ты… Я не знаю… Главное – не маячь тут. Где-нибудь в уголке посиди. Или в офис езжай. Иначе поймут, что тут что-то происходит.

— А по вашему присутствию не поймут, что что-то происходит?

— Нет. Мы ж типа студенты. Пришли измерять детали, собирать данные для диплома. Такие тут постоянно шастают, народу не привыкать.

— Не боишься? – серьезно спросила Марина.

— Кого? – поперхнулся Сергей. – Или чего?

— Ну… Не знаю.

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

— Ну как скажешь… — пожала плечами Марина. – Ладно, я тогда в заводоуправлении посижу, в переговорке. Если что – звони.

— Хорошо. – кивнул Сергей, потушил сигарету и решительно направился в сторону цеха.

— Ну что, как в старые добрые времена? – улыбнулся Толян, открывая тяжелую цеховую дверь.

— Лишь бы не как в тот раз… — грустно улыбнулся в ответ Сергей.

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

Я был на твоем собеседовании. Не на основном, а на кроссе. Я слышал, как ты рассказывал, что сам когда-то был программистом. Потом какими-то проектами внедрения руководил. Был очень успешным. Но за каким-то [фиг]ом пришел в нашу дыру.

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

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

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

А что есть выбор, выполняемый человеком? Это не мгновенный алгоритм, а процесс. У этого процесса есть начало, конец (дай-то Бог), и, главное – продолжительность. Сколько, по-вашему, может длиться выбор задачи?

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

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

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

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

Попробуем разобраться, так ли всё просто и однозначно.

Традиционный способ измерения задач в нашей отрасли – часы. Давайте посчитаем, сколько метрик в часах мы используем.

Первые, самые главные часы – те, что мы выставляем клиенту. В зависимости от ситуации, мы либо договариваемся о часах заранее, либо выставляем по факту – сколько затратил программист.

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

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

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

А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?

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

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

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

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

Структура книги давно известна, что там написать — тоже, надо просто сесть и сделать. Я написал, на данный момент, 6 глав из 20, т.е. ~30%. И, раз пошла такая пьянка, выложить их в виде статей. Девушка, кстати, прочитала только 3 главы.

Сейчас будет первая, вводная глава. Есть небольшая специфика — раз книга, по сути, создавалась на заказ, то она про разработку на 1С. Убрав упоминания 1С, я бы и сделал из нее третий продукт — это заняло бы полдня.

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

Друзья, нам с вами несказанно повезло. Тот парень еще не уехал, и я выпросил у него резюме. Не потому, что хочу взять его на работу — не тот я человек. Просто мне кажется, оно стоит того, чтобы быть опубликованным. Хотя бы потому, что в нем 22k букв. Вы еще где-нибудь такой кошмар встречали?

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

Итак, дальше — сплошная цитата без моих правок.

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

Наливайте чайку или кофейку, у нас тут лонгрид.

Не знаю почему, но вам понравилась история про одного парня. Если помните, он ушел.

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

Я, как вы поняли, с ним знаком. И не просто знаком – мы вместе учились на приборостроительном факультете. На носу День Радио, и он прилетел обратно в нашу дыру на встречу выпускников. Позвал меня выпить пива, и рассказал мне одну историю. Про одну девушку.

Основано на реальных событиях.

Сентябрь выдался довольно мерзкий. Чуть только стихла трель первых звонков, зарядили дожди, невесть откуда взявшиеся мартовские ветры, а температура по Цельсию вполне умещалась в один разряд.

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

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

– За кем? – спросил домофон.

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

– Что? За кем пришли? – в голосе слышалось явное раздражение.

– За Борей! – еще громче крикнул парень.

– Потише надо. – с улыбкой сказал второй. – У них там трубка фиговая, не услышат.

– За Борей я, за Борей. Борис. – спокойным голосом повторил первый, и вежливо улыбнулся, глядя на второго. – Спасибо!

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

– Папа! – раздался крик из-за угла раздевалки. – Мой папа пришел!

Гена родился в Советском Союзе. Хоть уже и на закате великой империи, но успел насмотреться на портрет Ленина на фоне красного флага, расположенный на первом развороте букваря. И, конечно, Гена обожал все, что касалось космоса. Гордился, что живет в стране, имеющей самый внушительный список достижений в космонавтике, каждый пункт которого начинался со слова «первый».

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

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

Если же вы испытали, или сейчас испытываете боль планирования в 1С, то давайте поболеем вместе, и попробуем выздороветь.

Статья написана, в основном, про УПП. Часть проблем удалось снять в ERP (заодно добавив новых), но боль осталась и по сей день.

Итак, поехали.