Comments 103
В этой статье изложена прям вся квинтесенция боли офисного IT-работника. Особенно про личные кабинеты.
В этой статье изложена прям вся квинтесенция боли офисного IT-работника.
И не только офисного IT-работника. Работал в нулевые на заводе. В точности такая же шняга на уровне всего. Совещания, собрания, отчёты, планирование, ещё раз отчёты, диаграммы Ганта. Доходило до абсурда. Эффективные менеджеры общались со старыми кадрами, выслушивали их предложения, потом задвигали их на собраниях как собственные, при этом не обладая необходимой компетенцией.
Надеюсь, что про ИИ шутка. Довольно грустная.
На западе в гуглах и фейсбуках менеджер это царь и бог для простого разработчика. А разработчик для менеджера это просто легкозаменемый ресурс. Все из за конкуренции с миллионами синьеров индусов готовых кодить с утра до вечера за тарелку риса с куркумой.
Боюсь, что менеджеры заменят всех других на ИИ, а не самих себя.
1) Выше уже приводилась необычное раскрытие раскрытие аббревиатуры ИИ, как
идиот искуственный
(для получения которого надо сопрячь Искусственный Интеллект
и весьма посредственного идиота белкового).
2) Что касается замены действительно грамотного персонала - здесь
надо не "перегнуть палку", иначе компания просто лишится возможности изготовления того продукта, что приносит компании прибыль.
Менеджеры нужны, но нужны хорошие менеджеры. Это как с плохим разработком, который вместо того чтобы сфокусироваться на разработке, фокусируется сугубо на паттернах разработки и занимается оверинжинирингом. Еще хуже, когда осознанно усложняет реализацию, чтобы увеличить bus фактор и делать себя незаменимым в компании.
Бывает на неделе по 3-4 созвона за день. Пустой день.
Я пытался в отчёт писать, что с 9.30 до 10.30 - написание отчёта за неделю. Но руководитель взорвался и сказал убрать!
И отменил отчёт за неделю?
Тогда остается добавлять 5 минут к каждой выполненной задаче?
Что-то вроде старого доброго "подготовительно-заключительного времени."
встречал аналогичную страшную вещь, под названием "фотография дня"... это нечто...
Встречал заочно в двух местах, не присутствовал и не организовывал.
Это только способ исследования процессов (качественный и количественный), где-то уместный, где-то нет. И не забываем про качество реализации (с учетом возможного саботажа сотрудников), корректных выводов из исследования и разумных решений на их основании.
У меня осталось стойкое впечатление, что манагеры пилили головы инженерам для получения подобных "фото" и "КейПиАйи", чтобы чем-то себя занять, ибо без таковых их (манагеров) ненужность выпячивалась слишком очевидно...
мне както ближе подход Генри Форда (та история, когда пусть технарь спит в кресле, если всё работает)
"Фотография рабочего дня" - вполне уместный и эффективный инструмент в нормировании на производстве, если им конечно же не злоупотреблять.
Так а на что заменить? Хотя, если он взрывается, возможно, ему кажется, что вам нужно делать это в личное время.
9.30 до 10.30 - написание отчёта за неделю
(Восхищённо) Вам на это всего часа хватает???
Я уже много месяцев час в день в отчетах списываю на документирование этих самых отчетов. Прокатывает. Подозреваю потому... потому что никто не читает этих отчетов.
По правде сказать, первая табличка, про сравнение решения и предотвращения проблем, одинаково работает как для менеджеров, так и для представителей любых других профессий, включая программистов...
Законы Паркинсона работают :)
Но не все так просто. Если про примеры:
Апполон - да, все прекрасно, но в той же статье есть бюджет, который в современой валюте оценивается в 178 ярдов зелени. Немало, прям скажем. Ну и надо понимать, что развитие шло последовательно, поэтому Апполон банально рос не с нуля, а из результатов предыдуших програм
Небоскреб- - ну такое, сейчас строят по 5 лет плюс минус, но высота то выше и сильно, а тут надо ж понимать, что чем выше, тем сложнее. Да и вообще, архитектурная сложность сильно растет с ростом высоты и доп. требований
В реальности, многие разработчики сознательно или нет дистанцируются от "не ИТ" вопросов, а их решать надо. Ну и также надо понимать, что разработчик задействован обычно где-то на половине от всего жизненного пути коммерческого проекта и видит только маленькую часть его. Поэтому часто кажется, что если я не вижу, то этого нет
А в целом, статья скорее похожа на стеб, чем на что-то серьезное :)
Не очень понятно почему стёб.
Просто я раньше работал в компании, где на каждые пять-шесть программистов, приходится по менеджеру, и к которой утверждения данной статьи очень даже применимы. Потому как зачастую ты тратишь больше времени на оформление бесполезных метрик, отчетов, инструкций и т.д. (бесполезны они потому, что время на них не идёт в учет KPI, и потому, ты тратишь время на работу, которая заведомо не приносит ни опыта, ни знаний, ни денег), вместо непосредственно написания самого кода. При том, что менеджеры зачастую даже не удосуживаются связываться с функциональным заказчиком, сваливая и этот процесс на разработчиков.
Резюмирую - автор статьи действительно попал в больную точку таких компаний, засилье управленцев в которых ведёт компании к их закату, ну или как минимум к стагнации
Просто все показано очень однобоко :) Что-то вроде передовицы газеты "Труд" :)
В реальности:
1) Метрики: это скорее вопрос руководителя, чем метрик. Если руководителю они нужны - вопрос к нему, зачем? К примеру, руководитель верит, что метриками можно оценивать своих сотрудников и потом выписывать премии. И тогда выходит, что вроде как метрика зло, в премия - добро. Но вот связь того, что первая стала причиной второй - вроде как не очевидна исполнителю. Какое-то противоречие наверное :) Метрика может быть и измерение SLA для заказчика, за которым стоят бабки. В целом, для многих баблосодержащих процессов нужны метрики, но смысла описывать это я особо не вижу. Кому интересно - тот видит
2) Отчеты: честно говоря, я не часто помню, чтобы девелопер писал отчет. Тем более отчет отчету рознь, к примеру test report - не просто отчет, а мега важный документ, который описывает текущее состояние разработки. Есть отчеты для заказчика, вот надо и все. Плюс заказчик чувствует себя "важно", когда ему чего-то говорят. Вот даже банальное - чего команда делала за неделю. Код разработчика ему на фиг не упал, а вот чтобы с ним поговорили приятно и показали прогресс - как ни странно надо.
3) Инструкция - опять же, разработчики просто не любят писать доку. Но вот когда разработка заканчивается, а вместе с ней все интересное - решение уезжает на прод и попадает в поддержку, которой неожиданно нужна детальная инструкция. Потому что у нее таких решений уже до фига. А потом через год возникает баг, и надо мучительно долго искать, "а как должго быть", а где "спека на интерфейс", а кто тот "чудак на букву М, к которому сейчас пойдем массажировать память".
Поэтому разраблотка кода - это далеко не все. Еще есть тестирование кода, сопровождение кода, доработка кода. Не нравится - ну такое, а без этого никак. Либо можно искать компанию, где доку не пишут :) Тут же ж не рабство, не нравится писать доку - можно голосовать "ногами".
Поэтому я и говорю, разработчик вообще видит малую часть жизненного цикла, и вообще "жизни", поэтому ему кажется, что все кроме кода - лишнее и ненужное. Спорить с этим мало смысла, так как надо прожить в нескольких шкурах, чтобы это понять. К примеру, не так давно, у меня, как у архитектора и по совместительству тех. лида (типа отвечаешь за тех. часть проекта) было одновременно два проекта у одного заказчика. В день минимум 8-10 удаленных колов, иногда 14+. Это не считая архитектурной работы. Но объяснять зачем они - трудно, тем более в формате ответа на комментарий. Проще наверное, когда разработчик просто пишет код на этом проекте и думает, что все остальное происходит само собой :) И не мешает ему так думать
Когда я писал про участие разработчика в половине "жизненного цикла" - это я польстил на самом деле :) В реале процентов 30, но надо понимать, что часть после разработки требует как раз документации
Код разработчика ему на фиг не упал, а вот чтобы с ним поговорили приятно и показали прогресс - как ни странно надо.
Это как вы правильно пишете нужно заказчику, но не нужно ни продукту, ни разработчику. Поэтому в приличных местах есть на проекте дешевый студент, который это готовит для РП или даже специальный подороже специалист по развлечению заказчика. В менее приличных этим занимается менеджер, конспектируя дейлики, в совсем неприличных это делают разработчики снижая свою эффективность на полчасика в день. А потом еще более дорогой по ФОТ менеджер это компилирует и скармливает заказчику. В клинических случаях - на встрече с заказчиком по чтению этого отчета присутствуют разработчики. Тогда эти встречи вообще золотыми выходят. И все ради "приятно"
Как ни странно, заказчик предпочитает общаться на одном уровне. Условно спонсор с аккаунтом, менеджер с менеджером, спец со спецом. Понятно жесткого разделения нет, но обычно не больше чем наложение соседних уровней. Для общения на высоком уровне надо "брифить" деталями соответствующих людей.
Также заказчик, помимо демо, просит отчеты, тест репорты, презентации с возможными решениями и т.д. Все это надо готовить и презентовать тем, кто в состоянии потом это все обсудить. Но опять же - тут вопрос размера проекта. Если "рога и копыта" пилят говноприложение - наверное сойдет и студент, но я уже давно в такого рода "конторках" не работаю.
А самое главное, все это имеет прямое отношение к деньгам, которые волнуют всех. И в том числе, казалось бы ритуальные танцы :)
-----------------------------------
В целом, если рассмотреть обычный проект, то:
Этап начальной установки контакта и сближения Это может быть конференция, случайная встреча, существующий контакт, публичный тендер, ... на этом этапе надо:
показывать что может своя организация: это могут быть презентации, технческие демонстрации
налаживание персональных связей
"непубличные формы общения", ... а как же, не все делается по честному :)
Коммерческое предложение Тут:
для тендеров готовить коммерческое предложение, которое может быть документом на 100+ страниц с кучем приложений, без тендеров в целом тоже самое :)
все это для большой организации может сопровождаться заведением "потенциальной сделки" в СРМ, в кучу других мест, так как часто на большой проект надо собирать солянку спецов с разных точек мира, которым надо где-то все это читать, дописывать, вносить правки и т.д.
где-то тут будут большая бойня за оценки трудозатрат между сейлами и деливери, которая будет тоже опираться на кучу документов
где-то рядом поработают юристы и финансы
и возможно получится контракт
если не получился, стоит проанализировать - почему.
Иногда может быть отдельный этап "Анализ" К заказчику высаживается команда спецов, которая уже детально смотрит чего и как и выясняет все, чтобы подписать контракт на "деливери". При этом может быть написано
архитектурное решение
бизнес модель и все остальное
оценки и т.д. Также продолжается "общение" с клиентом, чтобы максимально обедить его, что мы именно те, кто ему поможет
Что интересно, все это желательно где-то складывать, чтобы другие люди могли это тоже читать как "опыт", либо для понимание, как и на основании чего делать следующие продажи.
------------------------------
...... кстати разработчика тут еще нет от слова совсем ..... а документов и работы уже до фига
.... Пропуская этап разработки, получается продукт и куча доки для сопровождения. Хотя что интересно, этапы до этого уже могут легко затянуть и полгода, и год. А также куча отчетов по утилизации, проблемах и т.д.
------------------------------
Дальше самое интересное. Всем, а особенно владельцу бизнеса будет интересно подсчитать, а сикоко получилось (и получилось ли вообще) заработать на проекте. Если да, или есть нет - стоит сделать какие-то выводы и т.д. Выводы могут быть разные, например, как дальше работать с клиентом. Сколько ему выставлять денег и т.д.? Для всех этих решений нужна информация, и желательно побольше. Что интересно, хочется это отслеживать по ходу, чтобы понимать заранее, чего стоит ожидать. В том числе, чтобы принимать решение, стоит лит броаться еще за что-то, можно ли предложить больше ресурсов, или лучше аккуратно сввернуть работы и закончить по хорошему.
А так как часто каждый руководитель имеет свои планы по заработку денег, что важно понимать, кто сикоко принес и получил, чтобы потом понимать, нормально функционирует ли подразделение, или надо чего-то делать с этим . А для этого надо понимать, кто сикоко на проекте потратил, сколько было оценено изначально и как можно объяснить полученный результат.
Иногда приходит запрос на изменение условий контракта. Чего-то по скоупу поменять, по составу команды, по срокам. Просто решить проблему. Понимание финансовой и ресурсной составляющей, а также сути проблемы/задачи позволять принять решение что и как предлагать, и к какому варианту стремиться.
Итого получается, что всех интересуют деньги. Заказчику интересен текущий контроль, на что уходят его деньги, что он за это получает и стоит ли продолжать. Исполнителю тоже интересно, выходит ли он в плюс, и как можно еще что-то продать. Для этого надо много инфы, документов, и общения на разных уровнях.
А разработчик ... он просто пишет код и этого не замечает. Но от него требуется, как ни странно, давать первичную инфу, чтобы потом это свести в какие-то вменяемые результаты. И думает, что во вселенной только он, код и стадо тупых менеджеров. И магическим образом приходящая зарплата.
А еще есть аудиты и соответствия разным ISO, без которых вы хрен получите контракты в куче областей. А они требуют наличия в организации кучи документов, периодических обучений и т.д.
Я просто хочу показать, что помимо кода, и вообще работы эксперта на экспертном уровне есть еще куча задач. И их очень много, и часто для их решения нужна определенная инфа, понять нужность которой можно только покрутившись там. И можно либо попытаться понять, либо писать статьи на тему, я разработчик молодец и пишу код, а все остальные бездельники и только мешают. Каждому свое.
P.S. Лично мне все равно, кто с чем уйдет после прочтения коммента, но знание позволяет легче смириться с фактом необходимости делать что-то вроде написания доки, отметок в тайм менеджименте и т.д. Мне так точно
Дальше самое интересное. Всем, а особенно владельцу бизнеса будет интересно подсчитать, а сикоко получилось (и получилось ли вообще) заработать на проекте. Если да, или есть нет - стоит сделать какие-то выводы и т.д. Выводы могут быть разные, например, как дальше работать с клиентом. Сколько ему выставлять денег и т.д.? Для всех этих решений нужна информация, и желательно побольше. Что интересно, хочется это отслеживать по ходу, чтобы понимать заранее, чего стоит ожидать. В том числе, чтобы принимать решение, стоит лит броаться еще за что-то, можно ли предложить больше ресурсов, или лучше аккуратно сввернуть работы и закончить по хорошему.
И если первое, что увидит владелец будет строчка "30 минут из 8 часов - составление отчета" то у разумного владельца наступит просветление, и на проекте появится таки стажер-студент, который будет делать отчеты из видеозаписей дейлика и отдавать их РП. Так как "заказчик предпочитает общаться на одном уровне", то именно от имени РП будет уходить отчет заказчику, ну и коротенько пересказывать его тоже РП придется. Хотя может и специалисту по развлечению заказчика со звучной должностью, если РП реально занят, а заказчик любит шоу.
Т.е. вы предлагаете тушить огонь бензином. Там где и так Овер-менеджмент, добавить еще прослойку из студента, который накосячит описывая (не так понимая)или просто что-то не услышав). Нужно будет еще проверять его (а лучше обучать).
Ну дык, уметь надо. Я на таких проектах жил разрабом. РП сумел извлечь из студента пользу и экономию сил разработчиков и денег подрядчика. Заказчик был доволен, а как проект довести до финала без факапов - это была наша задача. С учетом того, что мы были хорошо прикрыты от непрофильной ерунды - ночевать на проекте пришлось только в неделю пуска. И то - дежурной смене, которая в основном спала, но готова была подпрыгнуть и решить проблему.
Так вроде статья как раз про то что все эти сопутствующие задачи и есть те самые ритуальные танцы, которые по большому счету и не нужны, но так принято и ничего не поделаешь
Ну а как разработчки придет к деньгам без ритуальных танцев? Если условный Вася готов кодить на шару - велкам, никто не против :)
Ну а если он хочет получать ЗП, то придется что-то делать еще. Процесс конвертации процесса написаня кода в живые деньги, как ни странно, требует большого числа "ритуальных" танцев.
И как ни странно, многие танцы выглядят ритуальными только потому, что тот кто смотрит на них - не понимает сути :) Иногда, чтобы понять суть, нужны годы. Или годы только для того, чтобы начать думать, что понимаешь :(
дистанцируются от "не ИТ" вопросов, а их решать надо
А откуда эти вопросы взялись? Конечно, далеко не всегда, но часто с подачи тех же менеджеров. В том числе с подачи менеджеров у заказчика, которые интересные требования придумали. Еще часто бывает цепочка менеджеров, когда решает все самый главный, остальные "передасты", но каждый съедает время и демонстрирует значимость.
К примеру, вопросы возникают на цепочке, где деньги сначала заходят в организацию, а потом выпадают на счету или в конверте у разработчика.
Такие же вопросы возникают в проектах, где есть отдельные бюджеты
Или интересные вопросы в части продаж, чтобы проекты вообще появлялись
-------------
Я ж не против, законы Паркинсона работают. Но недооценивать необходимость звена управленцев не стоит
Все книги Паркинсона, а заодно книга Лоуренса Питера кажутся стёбом, пока в них не вчитаешься.
Ну и также надо понимать, что разработчик задействован обычно где-то на половине от всего жизненного пути коммерческого проекта и видит только маленькую часть его.
Разработчик видит продукт в том виде, в котором он дойдёт до пользователя (либо свою часть продукта), но глубина этого погружения несравнимо выше, чем у менеджеров, которые, в свою очередь "сознательно или нет дистанцируются от ИТ вопросов", так что не вижу проблем.
Нираз видел как менеджер не слышит просьбы разработчиков слить требования заказчика и убедить его отказаться от фичи, потому что её разработка очень сложная с точки зрения кода и 100% будет требовать грязных хаков или перестройки всего проекта.
У менеджера задача ублажить заказчика, а не сделать продукт. Поэтому он согласиться даже на анальный фистинг всей команды по утрам.
Возможно всë потому, что деньги платят за наличие фичи, а не за еë отсутствие?)
Деньги платят за просто наше наличие. У нас оплата за год поддержки продукта, а не за фичи.
Менеджер как раз должен играть не на поле заказчика, а слушать разрабов. Мы раз 5 с нашим менеджером заминали СРОЧНЫЕ фичи и каждый раз спустя месяц о них никто не вспоминал. Наш менеджер даже создала систему как в анекдоте с 3 ящиками. Она три раза делала вид что про фичу забыли, нет времени и прочее. Только на третий раз фича шла в работу.
Заказчик был нами невероятно доволен и даже перед мои увольнением менеджер ушла на повышение, а заказчик так нами доволен был что подписал контракт на 5 лет.
Заказчик сам не знает что ему надо и 99% его идей это сиюминутный понос одного из управленцев или фича которая нужна 1 человеку из всех пользователей. Иногда приходится даже объяснять заказчику что его придуманое решение говно и им нужно вообще другое и о другом.
Менеджер как раз должен играть не на поле заказчика
Такие прошаренные менеджеры обычно свой бизнес запускают, а в компаниях на менеджерских должностях обычно работают "передасты".
Если вы делаете продукт для заказчика, то да - вы должны его ублажить. Он вам платит.
Другой вопрос, если менеджер - бездарь. Потому что именно он должен: разобраться чего на самом деле хочет заказчик, как это встраивать в продукт/проект и прогнозировать принесёт ли это пользу/деньги и т.д.
Заказчик деньги платит. Разработка рассказывает почем выйдет эта фича и дальше заказчик решает надо оно ему или нет. Предложение альтернативных путей приветствуется. Между «сделать вот так» и «не делать вообще» есть целый спектр разных решений.
У менеджера задача заработать денег и прокормить всю эту команду разработки.
По Апполону.
178 миллиардов бюджета на 7 лет, а реально на 13 лет так как программа была до 1975 года это в среднем 14 миллиардов в год. Современный бюджет НАСА на 2023 год это 25 миллиардов. Так что все таки что то с современной космической инженерией не так
178 миллиардов бюджета на 7 лет, а реально на 13 лет так как программа была до 1975 года это в среднем 14 миллиардов в год.
Не, ну так нельзя делить. Если в последние годы просто закрывали какие-то вопросы типа дописывания доки, то брать во внимание надо только активные годы. Иначе получаем классическую "среднюю температуру по больнице".
Плюс надо понимать, что Апполон при все своих достижениях был конкретным вложением под задачу. Тот же носитель (Сатурн) был, по сути, совершенной реализацией тупиковой идеи. Ее довели до ума, хотя это было люто дорого и безперспективно. Конечно, какие-то наработки использовались и далее (ракета - штука очень сложная), но базовая архитектура была изначально устаревшей. Это как идеальный карбюратор.
Поэтому выкинули Штаты очень много по сути, а брать эту программу как пример эффективной траты средств - ну такое.
Возвращаясь к истокам: автор статьи "топит" за Апполон как пример - "вот так надо". А в реале это чистой воды "all-in" сверх богатой организации. Повторить почти анриал. Надо иметь топовейший бюджет, конкретную цель и желание во чтобы то ни стало опередить конкурента.
----------------------------
А так да, про современное НАСА - трешак какой-то. При том, что маск куда дешевле двигает новации в той же области.
Возможно дело в отсутствии конкретной задачи и соревновании. Если бы была четкая цель и конкурент - то тут все было бы прозрачно. А так ... классика, когда бюрократия побеждает все
Где-то я это уже слышал
Где-то
- Давайте сделаем анализы, проверим диагноз.
- Нет, давайте сразу лечить, лечение быстрее.
(с) Доктор Хаус.
Такое в медицине встречается. Моя знакомая сталкивалась. Дело в чем - анализ занимает время и иногда продолжительное. И если он окажется положительным - то... может оказаться, что лечить будет уже поздно.
Скажем при укусе клеща рекомендуется сразу принять антибиотик, а потом уже разбираться - болеет клещ боррелиозом или нет. Или с бешенством так же - вначале сорок пять уколов, а если животное ничем не болело - ну и хорошо.
Утрирую, конечно, но в целом "врачей" таких процентов 90
А среди менеджеров-то!
Потому что, по правильному:
отправляем сдавать десяток анализов
пока, анализы будут готовы (а занять это может не одну неделю), начинаем лечить по симптомам (иначе, рискуем получить вскрытие трупа у патологоанатома)
когда анализы готовы, корректируем лечение
На, практике:
куча всех анализов может очень легко по сумме перевалить за $1000
в результате:
в платной медицине пациент может решить, что его разводят как лоха и больше не придти
в бесплатной медицине, обычно, просто, нет возможности сдать все нужные анализы на $1000
А все потому что технический работник это просто шестеренка в коммерческом бизнесе. Для бизнеса стремление к контролю всегда превыше эффективности затрат.
С другой стороны без команды конкурировать на рынке практически нереально. Это тупик.
Как вариант ситуацию может спасти децентрализованная разработка. Выпускайте свой токен и вперед. Но перед этим нужно получить финансирование. Опять без децентрализации не обойтись. И страхование. И возможно что то еще. В общем то это все реально уже сегодня.
Так в чем же проблема? Вероятно в костном мышлении разработчиков и нежелании менять ситуацию. Но это не точно. Возможно просто в психологии и страхе.
"Для бизнеса стремление к контролю всегда превыше эффективности затрат"
Что вы имеете ввиду? По моим наблюдениям нужен баланс контроля и свободы. Технические работники тоже люди со своими слабостями и часто предпочитают делать то что приятно/интересно, а не то, что нужно. А вот когда за спиной творца стоит менеджер с палкой то эффективность работы увеличивается.
Причём что интересно, по мнению сотрудника его эффективность падает, а по мнению менеджера растёт. А кто на самом деле прав в конкретной ситуации разобрать крайне сложно.
А чтоб точно понять, падает или повышается - нужно это как-то измерить... Опа, опять пришли к метрикам :)
Главное не превращать метрики процессов в KPI сотрудников. А то вместо цели проекта будет достигнут KPI исполнителя.
вместо цели проекта будет достигнут KPI исполнителя.
Каковой может оказаться прямо противоположным целям собственно проекта
В 1961 году у нас в Вычислительном центре АН СССР проводились расчеты наиболее экономичных путей доставки стройматериалов строительным объектам в Москве. Математики рассуждали просто: вот имеются заявки строительных организаций, которые должны быть удовлетворены. Этот критерий нам казался совершенно очевидным. Ведь цель управления —обеспечить строительные организации стройматериалами.
Но выполнить заявки можно разными способами; и среди них надо выбрать наиболее экономичный. А для этого достаточно — и это тоже нам казалось вполне очевидным, — чтобы путь, проходимый каждым самосвалом, везущим груз, был самым коротким. Так рассуждали математики; и на основе этих рассуждений была составлена задача оптимизации. Она получилась громоздкой, но нетрудной; и мы предвкушали быстрое и эффективное внедрение наших методов расчета.
Для эксперимента нам выделили автобазу, в которой было 80 самосвалов. Каждую пятницу к нам в Вычислительный центр привозилась кипа заявок на неделю вперед; в воскресенье ЭВМ для каждого самосвала печатала документ. В нем было все: и что и откуда брать, и куда везти, и каким маршрутом следовать! Казалось, мы сделали все правильно. Но в жизни многое бывает гораздо сложнее, чем на бумаге, и основные трудности оказались все впереди.
Прошло три месяца. Автобаза подвела квартальные итоги и увидела, что попала в глубочайший прорыв. План был не просто не выполнен — он был сорван; показатели работы были столь плохи, что оказалась под угрозой выплата зарплаты рабочим, и руководители автобазы потребовали прекращения эксперимента и возвращения к старым методам работы.
Так что же, спрашивается, мы оптимизировали? Что в таких условиях стоят все наши математические методы?
Несколько позднее, чем это следовало бы, мы вместе с руководством автобазы начали анализировать структуру показателей автобазы и обсуждать причины, почему математики сумели за такой короткий промежуток времени развалить ее работу.
Прежде всего выяснилось, что задачу, подобную той, какую мы сформулировали, раньше никто из должностных лиц автобазы не решал; просто без ЭВМ ее нельзя было решить за два дня! Раньше сами шоферы выбирали маршруты и получали премию за сокращение холостого пробега и экономию бензина. Далее, оказалось, что работа автобазы оценивается целым набором различных параметров. Основным для нее было количество тонна-километров, а потом шли второстепенные: экономия бензина, холостой пробег и многое другое. Не было только главного среди этих показателей — степени удовлетворения потребностей строительных организаций, то есть того, ради чего существует сама автобаза.
Вот и получилось, что, несмотря на то, что все заявки оказались выполненными, что количество тонн, которые перевезла автобаза, было гораздо больше того, которое она перевозила раньше, километров она не доездила, и не доездила много — так много, что основной план не был выполнен! А как он мог быть выполнен, если каждому шоферу был точно задан маршрут и нельзя варьировать холостым пробегом и экономией бензина!
Наша попытка «выяснить отношения» была отягощена традициями и взаимным непониманием. Если строго следовать требованиям базы, то ЭВМ легко дала бы оптимальное решение, но оно было бы абсурдным. Согласно ему автомашина должна была бы взять стройматериал, выехать на окружную дорогу, крутиться целый день вокруг Москвы, а к концу рабочего дня свалить этот груз где-нибудь поближе к автобазе и вернуться в гараж. В этом случае и тонно-километров будет много, и холостой пробег будет минимальным, и план будет выполнен — чего еще желать! И потребовалось время, большие усилия обеих сторон и активность вышестоящих органов, которым пришлось менять систему показателей, чтобы избежать случившихся нелепостей и наконец сдвинуть дело с мертвой точки.
Мне кажется, что у человеческого мозга есть некий предел понимания. Сложность систем растёт, всё меньшее количество людей реально может понять с чем взаимодействует и какова среда вокруг, замыкаясь в инфопузырях. Соусом сверху общий информационный перегруз получается то, что получается.
Как раз программа высадки на Луну - пример долгосрочного планирования
Что тут думать? - Прыгать надо!
Исторические подводки довольно сомнительны:
Космическая программа «Аполлон» от формулирования задачи (12.09.1962) до высадки на Луну (20.07.1969) заняла менее семи лет.
При этом трое астронавтов погибло, и ещё трое чуть не погибло. Ну и выявили тупиковую ветвь ракетостроения. Лучше бы не спешили.
Притчей во языцех стал проект высокоскоростного поезда между Сан-Франциско и Лос-Анджелесом, строительство которого началось в 2015 году. За это время бюджет вырос с
128 млрд, а сроки окончания строительства постоянно сдвигаются (и конца им не видно).
Вы ещё берлинский аэропорт вспомните или финскую АЭС. Просто, кто-то делает, а кто-то пилит бюджеты.
В цивилизованной стране вы уже не имеете права самостоятельно построить дом, проложить электропроводку или пробурить скважину, на любой чих нужно вызывать сертифицированного мастера с лицензией
Про скважину не знаю, а дом или проводку делайте на здоровье. На строительство нужно заключение архитектора, что крыша не упадёт вам же на голову. Про проводку вообще никто никогда не узнает. Разве что страховая заинтересуется в случае пожара
За последние 50 лет всё вокруг подорожало в несколько раз (даже с учётом инфляции): недвижимость,
Опять же смотря где, но в среднем она всё время дорожает
образование,
В цивилизованных странах образование стало бесплатным
медицина,
это сложный вопрос. Медицина очень изменилась. Ну и опять же, в цивилизованных странах стала доступней
те же космические программы.
Аполлон встал в 260 ярдов, Артемида, пока, планируется меньше сотни
Таковы издержки современной цивилизации, которая зациклена на процессах и процедурах
Она зациклена на безопасности и сохранении жизни людей. Для системного обеспечения чего и нужны процессы и процедуры.
Она зациклена на безопасности и сохранении жизни людей.
А в последнее время — также и на том, как бы ненароком не задеть чью-то тонкую душевную организацию.
Про проводку вообще никто никогда не узнает. Разве что страховая заинтересуется в случае пожара
Дом в большинстве случаев стоит дорого и является очень значимой инвестицией. Дома покупают-продают, их закладывают, берут под них кредиты и многое другое. Если выяснится, что вы своими шаловливыми умелыми ручками там наворотили всякого, то у вас будут большие неприятности.
вы не сможете продать такой дом иначе, чем с большой скидкой
если при продаже вы умолчите о самостоятельных переделках, и это вскроется, то вас ждут большие неприятности, вплоть до обвинения в мошенничестве
страховка обойдется вам дороже, а если об этом узнают после страхового случая, могут отказать в выплатах (всего-то)
если дом находится в залоге у банка, то вы останетесь и без страховки, и в долгах у банка
очень часто в пригородах дома находятся довольно близко друг к другу. Пожар по вине проводки может спалить пару соседних домов. Вы готовы оплатить весь ущерб из своего кармана?
в некоторых случаях можно получить уголовное преследование, если окажется, что по вине самостоятельного ремонта кто-то пострадал (ваши близкие, соседи, гости, которые к вам зашли на пикник и т.д.)
Надеюсь, теперь ваше мнение по поводу самостоятельных переделок немного изменилось. Это в СССР и пост-советских государствах предполагалось, что мужчина должен уметь все делать сам. Но при этом ответственность за самодеятельность была минимальная. А в странах развитого капитализма лучше, конечно, не экономить пару тысяч, рискуя влететь на пару миллионов.
Это была самая крупная оптимизация за много лет. Самого инженера назначили на десятки совещаний и заставили подготовить презентацию PowerPoint о проделанной работе.
Побуду адвокатом дьявола.
А может, не так и плохо, что разработчика не задвинули в угол, а дали возможность поторговать лицом перед руководством? Когда он пойдет за повышением, все вспомнят этот случай.
А может, после совещаний другие менеджеры спросят свои команды: Гайз, проверьте наши скрипты. Вдруг там тоже есть что оптимизировать?
Я живу в городе-миллионнике - Челябинске.
Лет 20 назад периодически видел пожары: пожарные машины, которые куда-нибудь ехали, выгоревшие квартиры и частные дома. Сейчас уже и не помню, когда такое последний раз видел. Те же 20 лет назад постоянно видел мужиков, у которых нет то пальца, то руки, то глаза. Сейчас почти не встречаю.Я не знаю, почему так, но подозреваю, что помогли регламенты и меры безопасности. К слову, самый безопасный вид транспорта в мире - авиация - является как раз-таки самым зарегулированным.
Я бы хотел видеть на дорогах только "сертифицированных водителей" (сдавших права), ходить к "сертифицированным врачам" (с вышкой по медицине) и общаться с "сертифицированными полицейскими" (участковые с корочками, а не казачья милиция).
согласен на 99% с вами, но такое чувство,что чем больше зарегулированность, тем страшнее цена ошибки. Если самолёт падает, это практически всегда 100% смертность.
Атомная энергетика, думаю, зарегулирована не меньше авиации. Имеем Чернобыль, имеем Фукусиму...
Пример что было до регулирования:
С 1948 по 1957 год во всем мире произошло всего 15 случаев захвата самолетов. В период с 1958 по 1967 год было захвачено уже 48 самолетов — опять же во всем мире. А вот с 1968 по 1972 год количество угонов превысило 130 — и это только американские самолеты. Порой угон самолетов в США происходил каждую неделю.
В 1968 году во время слушаний в Сенате представитель Федерального управления гражданской авиацией (FAA) Ирвинг Рипп заявил, что злоумышленникам ничего не стоит захватить любой самолет:
«Невозможно обыскивать каждого пассажира. Если у вас на борту есть человек, который хочет отправиться в Гавану, и у него есть пистолет — это все, что ему нужно».
Тогда сенатор от Флориды Джордж Смэзерс предложил, как кажется сегодня, очевидное решение — установить металлодетекторы или рентгеновские аппараты в аэропортах. Тем более, утверждал Рипп, такие уже успешно использовались в тюрьмах и на особо охраняемых объектах в США.
Но представитель FAA счел эту идею безумной. «Это очень плохо отразится на психологическом состоянии пассажиров… Это напугает людей до смерти. К тому же люди начнут жаловаться на вторжение в их частную жизнь»,— заявил Рипп. На этом споры о необходимости сканирования пассажиров и закончились.
Даже тут была статья про театр безопасности..
То, что вы приводите как аргумент достаточно спорно, т.к. в целом люди стали меньше творить всяких непотребств. Стали более доступны много более профитных занятий на длинной дистанции, чем захват самолетов.
Ну, предположим, летать надо всё же не каждый день. А вот рамки - не выборочные, а для всех в метро, уже перебор. У нас очереди к рамкам начинались еще на улице, а там холодно =)
А внутри перед рамками такая толпа, что можно взорваться прямо там - и успех будет гарантирован. Одним - потому что не пустили опасного террориста внутрь стратегического объекта, другим - ну потому что вот толпа, даже внутрь проникать не надо...
Что тут говорить, даже простую перепланировку в собственной квартире запрещено делать без подготовки проекта и согласования в исполкоме.
"я просто сделал проем в стене" - сказал сосед снизу, а стена оказалась несущей. в общем проблема как всегда не в менеджерах и не процессах, а в людях. слишком много людей. все они хотят вкусно кушать и ездить на хороших автомобилях. а думать они не хотят, к сожалению. вот и получается что залетает один такой на топ и тянет себе подобных по цепочке.
Все вышеописанное прекрасно ложиться на PAEI модель Ицхака Адизеса.
А конкретно - на жизненный цикл компании согласно этой модели
Если вкратце:
В новорожденной компании важно пахать и заниматься предпринимательством. Менеджеры должны сами не только генерировать идеи, но и уметь работать руками.
Затем компания растет, появляется необходимость администрировать процессы и интегрировать кучу людей. В состоянии сбалансированного "взрослого" компания может быть достаточно долго.
После чего рано или поздно наступает старость: предпринимательство гаснет, вслед за ним накрывается и производство. Остается одна бюрократия. c'est la vie
Не устраивайтесь работать в старые дряхлеющие умирающие компании. Пока они будут умирать ( а для корпораций этот процесс занимает от нескольких лет до десятилетий) вы будете страдать.
Читал-читал коменты, пожалуй эта модель лучше всего описывает - что происходит.
Если вкратце на пальцах - в зависимости от сложности проекта и наличия условных джунов, надо обложится процессами (бизнес анализ, системный анализ, код ревью, тестирование), чтобы не допустить багу на прод.
Для этого всего нужны люди-исполнители и люди-кто-управляет-людьми, чтобы те не отвлекались. Ну и как всегда есть крайность - компании, организации, где слишком много управленцев.
Может быть потому, что раньше люди (типа того монтажника с небоскрёба на картинке) работали по одной специальности всю жизнь и в большинстве были опытными самостоятельными профессионалами? А сейчас везде много где текучка рандомных людей, которые за 3 года выгорают и идут искать новую сферу?
С основными тезисами в статье я согласен, но кмк автор смешивает государственные регулирования с менеджерами в коммерческой компании. В доме, где я раньше снимал квартиру, сосед взял и без согласования снёс несущую стену, потому что "это его квартира и там он делает что хочет". Я не инженер-строитель, поэтому риски оценивать не берусь. Но жить в таком доме я больше не хотел. У Боинга двери-панели в полёте вылетают, потому что ослабили госурегулирование и отдали на откуп менеджерам (там всё сложнее, но мысль вы поняли). Смертность на дорогах снизилась, потому что ввели стандарты безопасности, которым должны соответвствовать автомобили. И так далее и тому подобное, до бесконечности.
Разумеется подобные регулирования увеличивают стоимость конечного продукта, в этом не (только) вина менеджеров. Их стало слишком много, и вместо того, чтобы не мешать работать они начинают доказывать свою необходимость, проводить бесконечные совещания-созвоны, вводить дополнительные бюрократические процедуры, плести офисные интриги ради повышения и так далее.
Для бизнеса стремление к контролю всегда превыше эффективности затрат.
Из моих познаний психологии и опыта работы, бизнесмен это во первых трудоголик, во вторых хочет не заработать, а на самом деле хочет управлять людьми. И компания это его личный цирк. Поэтому думать об эффективности своей работы если ты клоун в цирке это так себе. Единственный выход это открыть свой микро гараж бизнес и что нибудь клепать. А если вам этого будет мало, то значит вы сами трудоголик склонный управлять людьми.
По моим наблюдениям - всё же заработать, а люди - инструмент. И хороший бизнесмен- управленец - он еще и психолог-манипулятор. Причем наемные работники могут быть искренне уверены в хорошем к ним отношении как к личностям - по наивности, и как только дело доходит до спорных финансовых моментов - сотрудники или фрилансеры отправляются в пешее эротическое путешествие. Меня всегда удивляла, в этом смысле, какая-то акулоподобность успешных бизнесменов.
Интересная статья 👍❤️
Сегодня такие темпы невозможно представить ни в одной отрасли.
Телебашня Гуанчжоу (600м) построена за 4 года.
Если кто-то не может, это не значит, что никто не может.
А где мы свернули не туда? Откуда появились такие вот менеджеры и почему сейчас их количество с молодым поколением идет на убыль? Что-то же должно было послужить катализатором.
Что такое планирование? Планирование - процесс управления. Результатом данного процесса является управленческое решение, которое конкретно, к месту, ко времени, к процессу исполнения. Между прочим, результативность процесса планирования тоже можно измерить. Хотя бы с помощью бинарного измерителя, т.е. управленческое решение произведено или не произведено. Вообще, планирование - это вид деятельности, органичный для человеческой природы. Даже когда человек спит, его мозг выполняет процедуры планирования. Только человек не осознает, чем занимается его далеко не рациональный и весьма капризный мозг, когда выбраковывает неудачные варианты и представляет на рассмотрение подходящие. Так что вы в любом случае обречены планировать, коллега. Даже когда процесс планирования состоит из одного действия выбрать вариант, предложенный вашим мозгом. То, о чем вы пишете, коллега, по своим симптомам похоже на массовую неспособность делать выбор, производить, предоставлять управленческие решения в нужном количестве и нужного качества. Речь идет о количестве и о качестве, которые недостаточны. Примеры, которые приводите, говорят о низком уровне владения компетенцией "планирование". То есть о неумении формулировать решения, делать выбор и брать на себя ответственность. Но никак не о том, что планирование - вселенское зло, которое закрепощает и душит.
Классически - подписываюсь под каждым словом.
С каждым случаем знаком в реальной жизни.
Менеджеры и инженеры это вечный антагонизм и борьба противоположностей.
Менеджеру гораздо выгоднее решать проблемы, чем предотвращать их появление.
Каждый день , постоянно и непрерывно.
Какая-то бессмысленная простыня и "плач Ярославны". Ну да, есть плохие менеджеры ,так же как есть и плохие инженеры. Все же в конечном итоге зависит от конкретных людей на проекте.
Все это следствие развития средств производства. Автоматизация в производстве каждый день увеличивается и нужны все меньше и меньше людей на производстве. Лишним людям, зарплаты надо платить, потому что они должны выкупить всю продукцию автоматического производства. А просто так давать деньги пока не научились. Поэтому все лишние люди идут в услуги и в менеджмент. И они должны как-то «отработать» свою зарплату. А бюрократия, она такая – всегда порождает больше бюрократии.
Посмотрим как все это закончится. Я вангую, что начнут давать зарплаты просто так, чтобы не мешали и дела более-менее наладятся.
Готов подписаться под каждым словом статьи!
Туда же. Строительство Титаника.
31 марта 1909 года заложен киль, начали строить.
31 мая 1911 года спуск на воду для достройки = 2 года.
10 апреля 1912 года вышел в первый и последний рейс = 3 года.
Статья не в бровь, а в глаз.
Могу поделиться воспоминаниями советских времен. Отдел в п/я. Огромный, больше 200 человек. Три существенно разных направления работ, фактически миниНИИ. В понедельник у начальника оперативка с начальниками секторов, 30 - 40 минут. Этого ему было достаточно, чтобы быть в курсе всех работ и проблем. А все потому, что до того, как стать начальником, он успел поработать по всем трем направлениям и знал работы изнутри. Да и директора были все свои, из тех же разработчиков.
И с контролем исполнителей все было просто: есть конкретная задача, есть срок, обязан сделать. Когда и как ты это будешь делать, твой вопрос. Никто не следил сколько чем ты занимаешься. Не успеваешь за рабочий день, остаешься после, выходишь в выходной. Сделал раньше - молодец, у тебя появилось свободное время. Хотя обычно его тоже использовали на что то полезное - сачки у нас не приживались.
Конечно, были сетевые графики, акты, личные планы, но обычно вопрос стыковки двух сущностей, ССГ и реальности, отдавали на откуп экономистам.
Конечный результат? Сроки были существенно меньше, чем сейчас. Да и то, что советский задел по многим вопросам все еще, или совсем недавно, был актуален, само за себя говорит.
Какое то нытье подрастающего техноря, либо деда. Исследование в формате - я нашёл всё что подтверждает мою точку зрения опустив контекст и всё что противоречит желаемому.
Лунная программа управлялась автократично без долгих согласований, какой вывод? Жёсткая рука это хорошо? Этими же руками войну во Вьетнаме "не согласовывали". Стоила дешевле? На 6 умножьте для пересчёта в сегодняшний день. Закрыли потому что дорого, опасно, да и бесполезно.
А ещё самолёты забюрократизировали! Догадаетесь сравнить смертность?
Встречи бывают бесполезными? Да. А код бывает бесполезным или зря написанным? Да. Но тут логика - если код зря написали, то виноват менеджер который поставил задачу, а если встреча бесполезная, то виноват менеджер который её поставил?! ДА! Это называется ответственность, и чем выше позиция, тем она выше. Более того ошибки менеджера выглядят ни так как ошибки рабочих, образованного менеджера сложнее определить/нанять/обучить чем опытного исполнителя.
Но проблема не в том что технари молодцы (вот один сэкономил компании 5 или 10% на сервере), а в том что гуманитарному образованию и софту уделяют мало внимания, потому что это сложнее (оценить и развить). В примере разработчик сэкономил 500k$ , а не принёс в компанию! Это важно. Сэкономить может один сотрудник, а вот что бы заработать нужна команда.
В РФ супер финтех и госуслуги, но нет института авторского права, как и любого другого. Надо принять этот перекос в технарство и компенсировать слабую гуманитарную сторону.
П.с Кстати, почему вы не пишете "вот раньше Водопадная модель управления была, ууу!", и большинство проектов не сгорало как сейчас в ноль, а уходило в многомиллионные долги? Потому что аджайл (о, боже) имеет плохие примеры реализации и не достиг совершенства за 20 популярности?
Кажется автор несколько смешивает по крайней мере 2 проблемы: плохие (именно плохие, а не все) менеджеры и regulations. Хотя по сути и те и другие мешают гениальным программистам делать свое дело, причины у них несколько разные.
Плохие менеджеры - это очень часто встречающееся явление. Плохой менеджер и в самом деле хорошо описан в статье - плохо понимает что вообще происходит, зато активно всем мешает собирая метрики производительности, да еще и пытается всем показать как же он важен во всем этом процессе. Но есть хорошие менеджеры (я встречал и хороших, и плохих) - они помогают в движении по карьерной лестнице, а не занимаются жандармерией. Они хорошо понимают сильные качества своих подчиненных и ищут возможности чтобы подчиненные эти возможности реализовывали. Они улучшают взаимоотношения внутри команды. Они сами технически хороши и понимают что делают их подчиненные и почему это сложно, а поэтому могут адекватно оценить их работу.
Regulations - а это просто необходимо, потому как гениальных программистов, как и представителей других специальностей, гораздо меньше, чем, скажем так, не очень квалифицированных, зато почти все верят, что они “выше среднего”. И все regulations, как правило - это просто защита от дурака. Но если есть способ удостовериться, что дурака тут нет, то должен быть процесс убирающий ненужные проверки и согласования.
Хорошие тезизы про предотвращение проблемы или её героическое решение, но тут должна сработать квалификация вышестоящего руководителя, чтобы пресекать такие манипуляции. В частности, есть довольно простые способы:
индикативный подход, когда измеряются фактические результаты, а не впечатление от работы менеджера
различные KPI и OKR
завязка сразу на финансовые показатели
разделение функций исполнения и контроля
Грубо говоря, если двум менеджерам поставили задачу повысить аудиторию их приложений, один постоянно в мыле, героически решает проблемы, но аудитория не растёт, а второй ни разу не беспокоил начальство, но показатели растут - следующий важный проект дадут скорее второму. Но это если руководство - профессионалы. К счастью, в нашей стране с каждым годом хороших управленцев всё больше и больше, но случайные люди там ещё попадаются. Поэтому если вы попали к такому - просто найдите другую компанию)
>Деятельность менеджеров сводится к назначению совещаний, обсуждению вопросов, записи результатов совещания и планированию новых.
Это не менеджеры. Это, скорее, администраторы, обслуживающие процессы принятия решений.
> У менеджера совсем другая логика, ведь он думает не столько о продукте как ценности,
Это у вас какие-то неправильные менеджеры. Именно менеджер должен думать о принесении продуктом ценности, это его прямая задача.
Иногда лучше делать, а не планировать