Где теряется эффективность?

03.05.19

Команда - Лидерство

Общее понятие об эффективности командной работы. Где она теряется, где ее ищут, и почему ничего не получается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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



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

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

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

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

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

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

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

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

Резюме

 

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

См. также

Лидерство Бесплатно (free)

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

02.07.2024    3196    17    G.Shatrov    4    

11

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    573    0    Radio_Analyst    0    

5

Лидерство Бесплатно (free)

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

27.10.2023    4571    0    a.doroshkevich    27    

69

Лидерство Руководитель проекта Бесплатно (free)

Эмоциональный интеллект, как явление и направление, начали изучать сравнительно недавно – около 30 лет назад. Но за это время появилось уже немало знаний, которые можно и нужно использовать в управлении ИТ-командами. Как это сделать, участникам конференции рассказала консультант студии креативного консалтинга «Не просто ИДЕЯ» Ирина Шишкина.

18.11.2019    5988    0    user596192_shiiisha    7    

3

Лидерство Пользователь Руководитель проекта Бесплатно (free)

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    14890    0    andironenko    63    

46

Лидерство Бесплатно (free)

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

06.09.2018    15112    0    galina.petuhova_2015    41    

74

Лидерство Россия Бесплатно (free)

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

20.10.2011    107456    0    comol    489    

260
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. acanta 04.05.19 00:19 Сейчас в теме
Оба цикла, и Демпинга, и Голдратта как то подозрительно напоминают всеми нелюбимый do&fix.
Как вы их отличаете друг от друга?
Не хотите их объединить и вынести в общий модуль в целях повышения эффективности?

P.s.Очень понравился ваш эквалайзер на YouTube.
Тот, кто играет в танки поднимает дофамин, упавший от скучной и монотонной работы.
2. JohnGalt 58 04.05.19 12:05 Сейчас в теме
Эффективность вообще везде теряется. При любом движении. Идеальная эффективность - отсутствие движений. Практичность каждого действия зависит от того, что практиковать. Что считать эффективным. Цели можно достичь разными средствами. И процессы будут другие в зависимости от выбранных инструментов. Эффективнее, например, убить владельца желаемой собственности, чем произвести самому. Причем в тысячи раз эффективность повышается.
3. gubanoff 63 04.05.19 13:18 Сейчас в теме
(0)
В нашем случае – там, где человек не программирует.

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

Я тоже считаю, что лучшая доработка - отсутствие доработки. (тут есть нюансы, но общий смысл понятен).
eden_gmail; +1 Ответить
5. 1c-intelligence 12825 04.05.19 14:02 Сейчас в теме
(3) в вашей цитате речь об этапе, предшествующем программированию. Я говорю о том этапе, когда необходимость решения задачи программированием уже не отрицается.
6. acanta 04.05.19 14:20 Сейчас в теме
(5) Тут сложно сказать. Чтобы не потерять эффективность приходилось писать "запоем" с перекусами. Сейчас это неправильный подход.
Если кто то может работать в таком режиме вдвоем или больше это очень круто, поскольку обьяснять что ты делаешь тяжело, у каждого свой ритм жизни и мышления. Когда спринт готов, тогда можно показать и обсудить, но не раньше.
Как вы относитесь к тому, что ваш коллега попросит вас изменить название некоторых объектов метаданных и убрать некоторые свои объекты, потому что у него дублируется функционал или просто ему неудобно, они мешают?
Будете вы показывать оба варианта заказчику и ждать пока он обнаружит нестыковки и даст отдельное задание на исправления?
4. acanta 04.05.19 13:37 Сейчас в теме
Коэффициент полезного действия даже такого высокотехнологичного устройства как АЭС не превышает 21%. Неужели кто то ожидает от человека большей эффективности?
11. mpeg1989 131 05.05.19 14:02 Сейчас в теме
(4) А у трансформатора 98%. Только при чем тут это?
7. JohnGalt 58 04.05.19 16:55 Сейчас в теме
"Если рассмотреть цепочку создания ценности – от появления задачи до получения денег за ее решение – то мы увидим массу темных мест, в которых не происходит ничего полезного"

К сожалению, мы можем проанализировать только после завершения процесса и получения результата. Конечно, можно и нужно обобщать, искать и устанавливать правила. Но для новых проектов, команд, заказчиков и товаров они могут не сработать или привести к обратному результату. Особенно в наше время, когда среда динамично меняется. То, что написано вчера, неактуально завтра. То есть решать, как повышать эффективность можно только для рутинных неизменяемых процессов. Даже взять пример про выгрузку из УПП в Бухгалтерию. Если бы знать, что еще раз понадобиться ее писать, действия были бы другими.
8. 1c-intelligence 12825 04.05.19 16:59 Сейчас в теме
(7) процесс работы отделов фирм-франчайзи, решающих небольшие задачи клиентов, по-вашему, подвержен динамическим изменениям?
Я за ними наблюдаю недавно - с 2005 года, и заметил только одно ключевое изменение - почти вся работа делается удаленно. Для повышения эффективности это только плюс, т.к. все люди под рукой.
9. JohnGalt 58 04.05.19 17:09 Сейчас в теме
(8) Может это субъективное мнение, но считаю, что да. Состав и структура команд меняется, соответственно меняются методы и качество работы. Меняются продукты, меняются подходы. Что-то устаревает и становится ненужным (сходу небольшой пример - рисование форм в ОФ), что-то выходит на первый план (http-сервисы).
12. mpeg1989 131 05.05.19 14:06 Сейчас в теме
(8)
Для повышения эффективности это только плюс, т.к. все люди под рукой
Для конкретного клиента это минус, например, лично я никак не могу сделать одному удаленному клиенту задачу ибо постоянно появляются клиенты здесь и сейчас. Приходится скайп каждые два дня делать, чтобы это был тот дедлайн, которым я смогу откидывать все остальные входящие.
10. acanta 04.05.19 17:13 Сейчас в теме
На инфостарте наверняка кроме топ загрузок можно сформировать карту продаж и диаграмму направлений за последние месяцы, год..
То что сегодня уже устарело в центральных областях, вполне может быть востребовано на периферии.
Направление интеграции с другими системами развивается по мере роста популярности этих систем.
Продажи доработок в 1с по действующему стороннему функционалу и работающей интеграцией снижаются.
13. YaroslavHolovatiy 08.05.19 13:23 Сейчас в теме
(0) Автор, здравствуйте. Тема интересна и очень актуальна, благодарю.
Оставьте свое сообщение