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

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

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

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

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

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

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

Раз вы знакомитесь с этим материалом, то могу предположить один из двух вариантов.

Первый – вас кто-то заставил. Начальник, директор, руководитель проекта — не важно.

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

Кто вы, угадать тоже несложно: вы – либо программист, либо руководитель программистов, либо работаете в компании программистов, а может – и владеете этой компанией.

Зачем я обо всем этом рассуждаю? Лишь для того, чтобы сказать: расслабьтесь, и получайте удовольствие. Информация будет вам полезна, невзирая на вашу роль в компании.

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

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

Итак, поговорим об эффективности.

Посмотрите вокруг, на окружающих вас программистов. Кто из них прямо сейчас эффективно работает?

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

А вон те двое, которые о чем-то оживленно спорят? Кажется, об архитектуре какого-то решения? Они эффективны?

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

Один говорит – надо делать регистр накопления. Другой орет – нет, какой регистр накопления, ты чего, валенок? Только регистр сведений! Сколько это уже продолжается? Полчаса? Час? Вы там приглядывайте за ними, а то подерутся.

А вон тот, умник, ни с кем не спорит. Сидит в наушниках, подперев руками голову. Не программирует, это явно видно. А что он делает? Спросим?

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

Этот парень эффективно время проводит, как вы считаете?

Ну-ка, а вон тот. Рука быстро крутит колесо на мышке, сосредоточенный взгляд устремлен в монитор. Что у него там? Ага, знакомый список… Это же наши задачи! Что же он делает? Спросим?

Задачу, говорит, выбираю. Не знаю, с какой начать. Половина не понятна, половина – на толстых формах, а я их не знаю, ибо молод. Тут вот СКД надо знать, а я… Ну это… Так себе.

Этот эффективен?

Посмотрим на нашего чемпиона. Вот этот точно эффективен! Он такие решения выдает, закачаешься! В одного тяжелейшие проекты тянет! Что там у него? Хм, вроде макет какой-то рисует. Эй, чемпион, чем занят? ТОРГ-12 подправляешь? А чего там не так? Надо, чтобы вместо наименования договора выводился номер и дата? Серьезно? Такая задача?

Ну, мы, конечно, понимаем – клиенты попросили, надо – значит надо. Но почему ты, чемпион, эту задачу решаешь? У тебя, вроде, хватает больших, серьезных задач, уровня подсистем и новых конфигураций. Что, больше некому ТОРГ-12 подправить? Может, лучше вон тот парень, который задачу себе выбрать не может, справится?

Чемпион эффективен, как думаете?

А вон тот парень чего делает? Почему сидит возле телефона, и смотрит на него, как солдат на вошь? Звонка, что ли, ждет? Вроде нет, все звонки офис-менеджер принимает… Спросим?

Опа. Он должен позвонить клиенту, но боится. Уже два часа сидит и придумывает сценарии разговора, даже в блокнот что-то записал – фразы какие-то, свои прогнозируемые ответы. А почему он должен звонить клиенту? Он же интроверт до мозга костей. Так, стоп, у нас же каждый сам со своими клиентами общается. Что-то здесь не так, похоже…

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

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

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

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

Так где же теряется эффективность? В первую очередь – там, где человек не работает. В нашем случае – там, где человек не программирует. Хотя, как вы поняли, и программировать можно неэффективно.

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

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

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

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

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

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

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

Есть такое понятие – непрерывное совершенствование, родом из управления качеством. Слышали, наверное, про цикл Деминга, известный как PDCA.



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

Если знакомы с теорией ограничений Голдратта, то вот вам и оттуда картинка.



Слова написаны другие, но смысл тот же – цикличность. Совершенствовать, и совершенствовать, и совершенствовать. Предела совершенству нет.

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

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

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

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

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

Есть такая знаменитая формула синергии: 1+1=11. Она буквально означает, что объединение усилий двух человек может дать результат, в разы превосходящий простую сумму. Понятно, что эту формулу придумали маркетологи – доказать ее на практике еще никому не удавалось. Но посыл она дает правильный – команда может делать больше, чем коллектив.

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

Резюме

1. Любой человек, в любой момент времени, работает неэффективно;
2. Практически любое действие человека может таить в себе потерю эффективности;
3. Если на заниматься эффективностью проактивно, то она не изменится;
4. Эффективность любого человека имеет бесконечный потенциал для повышения;
5. Эффективность команды может быть выше, чем сумма эффективностей ее участников.