Comments 38
Что эффективно для одного, для другого может быть не очень. Или даже совсем не.
Полагаю, нужно начинать с осознания этой простой идеи. А также той, что интересы сотрудника, другого сотрудника, департамента, другого департамента, всей организации в целом — могут сильно не совпадать.
Приводить эффективность к одному направлению. Чтобы то, что эффективно для одного, было эффективно и для другого (или хотя бы ему не мешало), ну и т.д.
Если Вы пишете, что некто неэффективен — то сразу встаёт вопрос, ДЛЯ КОГО он неэффективен? Возможно, ДЛЯ СЕБЯ он вполне даже эффективен. Получает 100% зарплаты, работая 10% рабочего времени. Что тут неэффективного — ДЛЯ НЕГО?
С департаментами может получиться ещё интересней. Там вообще уникальные вещи случаются, особенно в банках и крупных компаниях.
Формула синергии? В кодинге, кмк, действует обратное правило: 1+1=1.5.
Если программист неэффективен, значит либо он перерабатывает, либо не получил специфицированную задачу, либо не любит свою работу. Во всех случаях виноват руководитель/тимлид/архитектор. Кмк, программу вообще пишет архитектор, а кодеры лишь пишут модули по его ТЗ. Я сам не видел, но мне так сказали… А если у Вас анархия, то лучший способ повысить эффективность — ввести роль архитектора и программиста-консультанта. Который скажет: делаем так. И будет отвечать за результат. Главное, чтобы он знал, что делает. ИМХО.
Если программист неэффективен, значит либо он перерабатывает, либо не получил специфицированную задачу, либо не любит свою работу.
Вариантов намного больше, мне кажется.
Навскидку:
1. Он недоволен зарплатой, но стесняется спросить;
2. Над ним иногда смеются, и он по 100 раз переписывает, чтобы не смеялись;
3. Его бросила жена;
4. На лестничной площадке завелись наркоманы;
5. Он — самый крутой разработчик, и вынужден поддерживать образ;
6. Его работа учитывается в потраченных часах;
7. и т.д.
Любая причина может привести к неэффективности. Их столько, причин, что фантазии не хватит все собрать. Но я и не пытаюсь. Просто предлагаю принять и согласиться, что неэффективны все. По-разному, но все.
Если считать себя или своих людей эффективными, и ставить шлагбаум «не, не про нас, и вообще херня», то всё так останется. «Нет» вообще хорошее слово — сказал, и думать не надо.
Так надо отделить мух от котлет. Классифицировать причины. На причины профессионального генезиса и личностного. И получится книга по управлению проектами + управлению персоналом. Но такие уже есть.
У них есть один недостаток — в них все классифицировано непонятной неопытному человеку классификацией, и эта классификация может быть ему непонятна. Можно написать свою, свалив все в кучу, оставив одни примеры, без претензий на систематичность и полноту.
Грубо говоря, если программист неэффективен, значит либо Вы плохо руководите проектом, либо у него что-то случилось, либо он неопытен, либо он такой сам по себе. Личные проблемы нужно обсуждать, если это травля в коллективе — агрессора увольнять, если он чего хочет — разговаривать, если личные проблемы — не знаю что делать даже, если неопытен или работает вполсилы — снижать оплату… Как-то так.
Кстати, неизвестно, эффективен он или нет. Может он напишет модуль, который потом пять лет будет из проекта в проект без доработок использоваться. А кода там мало, и пишется он долго. Т.к. нужно спрогнозировать все перспективы использования. И такое бывает.
Во всех случаях виноват руководитель/тимлид/архитектор.
Вы выполняете какую-либо из перечисленных ролей? В неэффективности выполнения этих ролей, тоже есть список виноватых? :)
Двое спорят? А кто эти двое? Если архитекторы, то зачем их двое? Если кодеры — почему они вдвоем пишут один модуль? Снова ИМХО
Двое спорят? А кто эти двое? Если архитекторы, то зачем их двое? Если кодеры — почему они вдвоем пишут один модуль? Снова ИМХО
А пожалуйста:
Архитектор Бизнес-Решения и Бизнес-Системы
Архитектор Программист и Архитектор инфраструктуры
Молодой кодер учится у старого или наоборот.
Модуль большой.
Один пишет, другой тестит
Чорт… Очень хорошо, но практически бесполезно...
1) Примеры неэффективности разных членов коллектива
2) цикл Деминга
3) цикл TOC
Статья стала бы сильно полезней, если кроме п 1. показывала бы реальные кейсы с решениями. С другой стороны — ежедневные публикации от автора позволяют надеяться, что скоро мы сможем увидеть и реальные кейсы с решениями.
Но это же и значит, что если ты выполнил норму по гайкам — то не обязательно сидеть и ждать, пока для них болты сделают.
Можно приложить усилия рядом.
И это упирается в вопрос — а зачем это мне, не так ли?)
Я допускаю и даже сразу признаю, что мой опыт может быть меньше Вашего. Однако, уточню — инициатива не всегда наказуема, а бывает, что даже поощряется.
Но это из моего меньшего опыта.
Это воодушевляет — но увы, рассчитывать на такое опасно.
Лучше ничего такого себе не позволять — результат непредсказуем (точнее, он вряд ли будет хорошим). Если хотите «вперёд и вверх, к сияющим вершинам» — лучше хобби или свой бизнес.
Есть на рынке организации, где данный процесс выстроен и работает.
Но они редки, согласен. И у нас они сильно реже встречаются, нежели в странах где практикуется правильная корпоративная культура.
А допускать такие моменты в организации, которая для этого не приспособлена — чревато, как я уже сказал, согласен.
За «усилия рядом» В ЛУЧШЕМ СЛУЧАЕ поставят на вид, чтобы не совался в не в своё дело.
я бы прям посмотрел на кейс данного проекта, где членам команды нельзя помогать друг другу
Вы очень верно заметили про мотивацию.
Но каждый сам находит свой баланс, что одному — зло, второму — "изи мод".
У меня есть другой контрпример, к сожалению, и это не про соки. Когда все идет хорошо, и ты расширяешь это "рядом", где-то просто советом, где-то делом. А потом это становится для всех привычкой. И ты уже сам не рад. И "мотивацию" за "не твою" работу забирают, ведь ты ж ее делаешь уже n времени. А потом еще и депремировать из "твоей" части могут начать, если ты подзабиваешь.
И это упирается в вопрос — а зачем это мне, не так ли?)
Ну один раз приложил усилия, и стал постоянно это делать — всё же просто.
Её бы хотелось дополнить установкой «все хорошие и стараются как могут», чтоб смягчить возможные демотивирующие последствия. Холиварная тема, наверное, но обсуждать её стоит в главе про мотивацию и ценности. Или в отдельной книге об этом )
А ещё можно добавить определение эффективности и методы её измерения? Навскидку я бы измерял в 1С аутсорсе прибыль, сарафанное радио, отток клиентов.
Ведь, как я понимаю, это не просто так размышления в слух, этот текст вам заказали, вероятно не бесплатно (хотя все может быть), а значит — это какой-никакой, а труд. Работа.
Я прочитал. Я вообще не понял, что автор хотел этим сказать. Все работают плохо, могут лучше и надо стремится быть эффективнее?
Во-первых, это спорно: кому надо? Работнику или работодателю? Работнику так-то не очень надо — чаще умение пускать пыль в глаза важнее эффективности в плане конкуренции. Работодателю? Пожалуй да, но статья не похожа на текст, вида «Как заставить своих сотрудников больше работать за те же деньги...»
Во-вторых, это очень много «воды», с очень низким содержанием смысла. Похоже просто на раздувание текста, когда заказали «20 тысяч знаков». Резюме вполне может заменить весь текст, да и само резюме — набор банальностей. Может быть это вводная и дальше будет лучше…
С вашей точки зрения, говно лежало всегда и так и будет лежать каждый год дальше, выползать из под снега и радовать своими красками.
Я лично считаю, что суть идеи в борьбе с невежеством и некомпетентностью любого рода.
Я лично считаю, что суть идеи в борьбе с невежеством и некомпетентностью любого рода.а на каком, собственно основании вы так считаете? Если бы автор писал нечто подобное, он бы так статью и назвал. Вернее курс статей. Но он пишет об ЭФФЕКТИВНОСТИ. Это как бы не одно и то же! Можно быть весьма компетентным, но ни разу не эффективным, а можно и наоборот. Так что это ваше мнение оно как-то… спорно.
С вашей точки зрения, говно лежало всегда и так и будет лежать каждый год дальше— lol. Вы может перечитаете еще разок? Мое мнение было: автор, когда писал эту статью был неэффективен. Он может лучше.
> Он может лучше.
Да, вы правы, здесь я поторопился.
Вы абсолютно правы в том смысле, что отношение к делу и эффективность — связаны напрямую… В отличает от многих других вещей, например, той же самой пресловутой компетентности. НО вот ведь вопрос: а цикл Деминга — он как связан с отношением к делу? ;) Типа если не используешь его в работе — то и отношение, значит, так себе?
Или вот есть человек, застрял в своих рабочих паттернах древних, совершенствоваться не хочет от слова «совсем», и в узком смысле — чертовски эффективен, да и за проект «всей душой», но все эти ваши агил-шмагил, Деминг-шменинг… Вертел он все это. Что с ним делать?
Ответы есть. И даже в комментариях к статье — полно. Синергия достигается при использовании сильных сторон каждого члена команды и нивелировании слабых. И кому-то нужно постоянно расти над собой, а кого-то просто — не трогать.
Эффективность — это не про самосовершенствование, а про… Наверное да — про управление. Но только не из разряда «эффективных менеджеров» — я не знаю, мне кажется или есть оно или нет. А все вот эти техники, тренинги, методики — хорошего управленца сделают лучше. А плохого — превратят в того самого «эффективного менеджера».
А что до работника… Мы живем в странном мире. Эффективность зачастую — это способность делать в два раза больше за те же деньги. Есть множество других навыков, позволяющих продать себя подороже, не особенно перетруждаясь. Нет, если ты сам уже понял, что пипец — ниже скатываться некуда, прокрастинация не дает выполнять даже минимальный объем работ — то да. Нужно с этим что-то делать. Ну или да — выяснить, может ты просто занят не свои делом? Что возвращает нас к началу: все зависит от отношения к к делу — золотые слова.
ЗЫ все это конечно про людей с наработанной практикой. Если ты не можешь сделать простейших вещей без гугла и просто еще не постиг платформу — если тебе нужны сутки на то, что пишется за 20 мин. Тогда эффективность и правда низковата и самосовершенствование не помешает. ;)
Про резюме.
1, 2. Не загружен работой по максимуму — это ещё не значит, что неэффективен с точки зрения работы предприятия в целом. Про это же Голдратт писал, верно? Главное, чтобы не было торможения работы узкого звена.
- «Бесконечный потенциал повышения» — звучит пафосно, только ради пафоса и написано, поэтому с этим пунктом не спорю.
Очень хочется прочитать главу про то, как не будучи руководителем доказывать эти тезисы сверху.
Какие конкретно тезисы из статьи вы собираетесь доказывать «сверху» (или сверху -тезисы?), не будучи руководителем?
Например, тезис о том, как не закрывать глаза на проблемы, а наоборот, выносить их как можно быстрее наверх и быстрее на них реагировать.
Сверху означает «с начальством».
Если узко понимать цикл Деминга, как цикл разработки, т.е. если грубо — проверять решение, прежде чем внедрять по-живому — тут все зависит от размера команды.
Если в штате один программист — вы, я думаю ваш шеф не будет против того, что бы вы свой рабочий процесс формализовали максимально возможным образом. Если конечно это не значит, что на изменение печатной формы вам нужна неделя! ;) Но мы тут вроде за эффективность, а не бюрократию.
Если команда относительно большая, и вас бесит, что нет нормального цикла разработки-проверки-внедрения, боже упаси навязывать свое мнение всем! Выстройте свой процесс: пусть все знают, что непроверенное сырое решение, баги и тп. — это не про вас. Все, что делаете вы: формально строго и выверено. Довольно скоро начальник подумает, что это, черт возьми, стоит взять на вооружение! ;)
Если же вы о том, что постановка задачи меняется на ходу, формального ТЗ нет и все ваши попытки что-то формализовать разбиваются об общий бардак в компании… Тут у меня четкого ответа нет. Тонкую грань между «так надо бизнесу» и «да пошли вы на… с таким ТЗ» каждый находит себе сам. Все крайне сильно зависит от уровня поддержки, которую имеет….Ну скажем так ИТ-управленец. Может он объяснить, что есть минимвальный уровень формализации процессов для их принципиальной выполнимости, а так же некоторая зависимость результата от степени соответствия процесса его формализованной сути, или не может — это уж как повезет.
Ну и где она?