Я наверное безнадёжно отстал от жизни - ну вот какая функциональность есть у мобильного приложения банка, чтобы её нужно было делать ЧЕТЫРЕ года?? За это время фотошоп, или, ладно, из современного, телеграм написать можно спокойно!
Единственно хочу отметить, что во многих источниках Наполеон приводится в пример как человек уделявший огромное внимание логистике, его успехи во многом базировались именно на тщательно выстроенной системе снабжения. Как раз он стряхнул пыль с упомянутых римских принципов мобильной войны, и переосмыслил их на новом уровне развития военного дела. Поэтому мне кажется некорректно говорить о том что он не уделял снабжению должного внимания, скорее речь о том что он не учёл особенности русского театра военных действий в своих планах. Например здесь https://logisticsmgepsupv.wordpress.com/2023/05/31/napoleons-logistics-the-art-of-sustaining-empires/
Казалось бы какой прекрасный мир, в котором все действия регламентированы. Т.е. разработаны алгоритмы буквально на всё. Включая обработку нештатных ситуаций. Но так не бывает, это иллюзия, разбивающаяся о реальность. Нарисовать всеобъемлющую инструкцию возможно только для полностью детерминированного мира. А в любом реальном есть взаимодействие с непредсказуемыми факторами. Можно конечно попробовать учесть их все, но как показывает практика оно либо не получается, либо инструкция распухает настолько что ей невозможно пользоваться. Но всё бы ничего, если это было бы единственной проблемой! Номер два - ресурсы. Они всегда ограничены, поэтому их на всех не хватает. Ты можешь сколько угодно писать что должно быть сделано то-то и то-то, но когда у тебя некому или нечем это сделать.. А если это можно не делать или чем-то заменить, возникает вопрос - а правильно ли спроектирован процесс? И переходим к самому интересному. Правила сами не соблюдаются. За ними нужно следить. И к тому же наказывать тех кто их не соблюдает. Чем больше правил - тем сложнее в них разбираться, тем больше контролёров нужно. Задача контролёра - не сделать хорошо, а сделать по инструкции. Это не из вредности, это by design. Поэтому начинает расти ком проблем - власть в карающем органе опьяняет, подловить на несоблюдении какой-либо инструкции можно любого. И неважно, есть тут злой умысел при административной борьбе, просто вредненький человек, или искренне хочет выполнять свою работу. Инструкции после определённого момента, по мере увеличения их количества, начинают не помогать, а вредить процессам, а увеличиваются они потому что толпа контролёров плодит и совершенствует инструкции до бесконечности, даже если сами понимают что некуда - ибо этим они поддерживают видимость своей работы и пользы. И в результате благая идея заменяет полезную работу на соблюдение инструкций. Производительность падает, люди увольняются - те кто работать не хочет принимают правила игры и начинают использовать инструкции для обоснования ничегонеделанья, а кто хочет получают постоянные выговоры за их несоблюдение. Но идёт это постепенно - поэтому это сложно заметить, долгое время руководство радуется как у нас всё гладенько и ровненько, пока не приводит к полной финансовой несостоятельности. Поздний СССР - все строго соблюдают миллион правил, поэтому стройки идут уже не годами, а десятилетиями, но зато всё по инструкции.
"Внедрение регламентов и инструкций сначала однозначно увеличивает эффективность работы, потом эффект становится разнонаправленным, но после какого-то момента начинается обратный процесс снижения эффективности, вплоть до драматичного."
Здесь есть несколько моментов. Да, знать регламенты необходимо, потому что это помогает защитить себя. Без вариантов. Нормативка на самом деле очень правильная вещь - я долгое время шарахался при слове ГОСТ, но погрузившись в тему понял насколько стандартизация полезная штука. В том числе когда компания создаёт внутренние "ГОСТы". Беда начинается, когда к делу подходят комплексно и решают регламентировать всё что видят - тогда вместо регламентов помогающих работать появляются бесконечные тексты про то как надо содержать рабочее место, общаться с коллегами, проводить совещания, оформлять переписку... И главное само по себе оно может и неплохо - но как лавина погребает под собой всё разумное. Как раз вчера обсуждал эту тему и набросал небольшую заметку по мотивам, может какие мысли будут интересны.
Проблема не в том что регламенты читать не хотят, а что любая уважающая себя компания плодит их быстрее чем успеваешь их читать :). Вывод в "итого" абсолютно верный, хочу только отметить что когда регламенты читают исключительно для того, чтобы не подставляться, это очень хорошо характеризует эти самые регламенты. Значительная часть их написана не для организации работы, а для избегания ответственности, как табличка "купаться запрещено" - всем всё равно можно в этом месте на самом деле купаться или нет, а смысл её чтобы если я утону за это никто не отвечал.
И всё вернётся на круги своя. Исчезнут тысячи выпускников ит-курсов, в программирование будут идти только увлечённые люди. И - да, компании, которые захотят сохранить серьёзную ИТ-экспертизу, будут растить их у себя.
Как компании успешно применяют хитрости (латеральное, оно же хакерское мышление) в налоговой оптимизации! Как порой в ущерб репутации рвутся удешевлять состав продуктов! Но при этом в расходах на ИТ — все настолько, наоборот, бесхитростные, конформисты и благотворители, что создается впечатление, что мир сошел с ума!
Прекрасная аналогия - можно развивать продукт, не экономя на проектировании, комплектухе, обслуживании, не лезть в "хакерские" схемы налогообложения - а можно "оптимизировать", впаривая потребителю ненадёжный, некачественный или вообще опасный продукт, и иметь наготове билет через Беларусь в Эмираты, чтобы попытаться успеть им воспользоваться когда налоговая наконец заметит эти шалости. Вот с IT - ровно то же самое. Треугольник никто не отменял - чтобы сделать дёшево и качественно, требуются высококвалифицированные специалисты, чтобы понимать, где можно экономить а где не стоит. Вот только захотят ли они биться с "эффективными менеджерами" за каждый мегабайт оперативки?
Зачем платить зарплату начинающему специалисту и ждать 7 лет, пока он вырастет до уровня senior?
А сеньоров будут выпускать "курсы по подготовке сеньоров"? Программист [если] становится сеньором, только пройдя весь путь от джуна, набравшись опыта и насобирав шишек.
Только нельзя забывать что эта красота не бесплатна - подробное описание задачи само по себе ресурсоёмко, чётко, коротко и ясно сформулировать не так просто. Поэтому важно контролировать баланс между потенциальными выгодами и потерями - насколько проблемы с потерей контекста обойдутся дороже чем ковровое документирование? Я ни в коем разе не призываю к односложным тикетам для галочки, по которым вообще ничего не понятно, что и зачем нужно сделать, а исключительно обращать внимание на адекватность формализации, чтобы не организовать самим себе итальянскую забастовку. А шаблоны заполнения тикетов - очень правильно.
На вопрос что такое успешный проект всегда хочется уточнить - "а для кого успешный"? Статья кратко намекает, что фактические критерии успешности не всегда совпадают с их формальным определением, но самое-то интересное - и что дальше, что с этим делать?
Я полностью поддерживаю тезис, что значительное количество пользовательских интерфейсов профессиональных приложений не от мира сего, "проектировались" теми кто имел очень смутное представление о выполняемых в приложении задачах, и представляют собой нагромождение кнопок, цифирок и менюшек. Иногда просто диву даёшься, это ж какое изменённое сознание надо иметь чтобы так неудобно сделать. С другой стороны, теперь проектированием занялись "профессиональные дизайнеры", и стало ещё хуже, появился "интуитивно понятный интерфейс" с большими кнопками, интервалами, управлением мышкой, скроллингом итп. Дело не в том, простой интерфейс или сложный, а насколько он соответствует выполняемым задачам. Более того, в хорошо сделанном "сложном" интерфейсе работать быстрее и проще, но это требует обучения и тренировки. Банальные шорткаты абсолютно не интуитивны, но ускоряют работу в разы по сравнению с мышкой. Поэтому надо понимать, хочешь ты сократить усилия на обучение, или улучшить качество работы (ускорить, упростить, уменьшить ошибки, снизить утомляемость..). При этом само собой необходимо оценивать, ради чего тратятся неслабые деньги - чтобы сотрудник выполнял больше полезной работы, или получил больше времени гонять чаи на кухне? При этом категорически поддерживаю замечание, что мнение пользователей системы обычно мало кого интересует ("менеджеры продают топам").
И ещё часто пишут о слишком больших издержках на кросс-коммуникацию между всеми участниками проекта, но почему-то одновременно поощряют их в "эджайл-стиле", называя это вовлечённостью в проект. Я считаю что сотрудники должны быть хоть и не изолированы от внешнего мира, но огорожены от внешних воздействий и непрерывной коммуникации со всеми подряд. (Особенно это пагубно, когда интроверты-разработчики сталкиваются с экстравертами-менеджерами). Это мало того что выбивает из рабочего ритма, так ещё и путает приоритеты исполнения. В таком случае руководитель не может нести ответственность за своевременное выполнение задач, и получается что "никто не виноват", только работа недоделана.
Понятие "лучше" не существует в отрыве от задач и исполнителей. Поэтому так часто проваливается попытка внедрения "лучших практик". Плюс важным фактором является представление о прекрасном высшего руководства, как оно считает "правильным", да и банально характеры сотрудников. Поэтому я бы ответил, что правильным является использование комбинированной структуры - но загвоздка в том, что как она должна выглядеть ответа нет. В качестве не часто упоминаемых, но на мой взгляд важнейших факторов, хотел бы отметить наличие персональной, а не коллективной ответственности за результат.
Мне кажется, что рациональная схема гибрида - это когда на базе функциональной структуры, с единой точкой входа задач в отдел, формируется проектная структура на уровне не рядовых сотрудников, а руководства подразделения. Т.е. все руководители отделов (или их замы, не суть), видят не отдельные сыплющиеся им на вход задачи, а весь жизненный цикл ведущихся проектов, имеют понимание об их объёмах и приоритетах, и уже в зависимости от этой картины приоритизируют задачи внутри отдела. А каждому проекту назначается проджект, который является фактически администратором.
В общем, тут можно теоретизировать до бесконечности, а потом выясняется что у тебя в "кросс-функциональной команде" то одни энергичные джуны, то мидлы работающие строго с 10 до 6, то сплошные сеньоры тянущие одеяло на себя :)
Статья как раз о том что административными мерами смысла бороться с совещаниями нет. Надо не их ограничивать, а процессы налаживать, ведь по факту совещание это костыль для процесса, когда требуется ручное управление. Моё ИМХО что если совещание меньше 15 минут, то вопрос можно по телефону обсудить, больше времени потратишь пока до переговорки дойдёшь.
Так можно и не 7 стратегий написать - только они все называются "найти уникальную фичу вашего бизнеса". И об этом говорят из каждого утюга про правильную рекламную стратегию. А одинаковые они получаются не потому что кто-то не знает этот секрет Полишинеля, а потому что разбираться с каждым, искать индивидуальный подход - это дорого, а надо чтобы быстро и дешево. Как у того юриста из примера.
Как эти методики оценки ни назови - они являются лишь различной обработкой экспертных цифр оценки. Которая выбирается в зависимости от того, какой из вариантов результата больше нравится оценивающему :)
У нас был "крутой" компьютерный класс - "цветных" ямах было штук 10, с одним дисководом, "учительская" с двумя, и ещё пачка чёрно-зелёных. Написал на бэйсике первую игрушку, с использованием спрайтов! Вообще машина по тем временам космос была, по сравнению с IBM PC - когда открыли новый класс с писюками, я поначалу был в шоке от убогих мониторов CGA и 5" дискет. После 256 цветной графики и 8 канальной музыки!
А в чём необходимость вообще обновляться на полюсе?? Без какой такой функциональности телефона Samsung нельзя обойтись до возвращения на большую землю?
И как учитывать такой момент, что люди будут стараться попасть в установленный срок, даже неосознанно. Если заложили многовато то станут более тщательно тестировать, делать код "получше", если маловато - то торопиться, местами откровенно тяп-ляп. В результате получается подгонка решения под ответ - оценка сроков будет "точная", а качество продукта при этом очень сильно плавать. Тогда planning pocker нужно применять и далее - чтобы исполнители не знали, какой реально срок был назначен :).
Кажется лёгкой цифра "фактическое время". А насколько она точна? Как выцепить время потраченное именно на реализацию данной фичи на фоне параллельно реализуемых задач? Например, реализация фичи по (консолидированной) оценке должна была занять 40 часов. А сделали её через месяц. Сколько времени из этого месяца занимались именно данной фичей, чтобы можно было понять, попали в оценку или нет?
Я наверное безнадёжно отстал от жизни - ну вот какая функциональность есть у мобильного приложения банка, чтобы её нужно было делать ЧЕТЫРЕ года?? За это время фотошоп, или, ладно, из современного, телеграм написать можно спокойно!
Единственно хочу отметить, что во многих источниках Наполеон приводится в пример как человек уделявший огромное внимание логистике, его успехи во многом базировались именно на тщательно выстроенной системе снабжения. Как раз он стряхнул пыль с упомянутых римских принципов мобильной войны, и переосмыслил их на новом уровне развития военного дела. Поэтому мне кажется некорректно говорить о том что он не уделял снабжению должного внимания, скорее речь о том что он не учёл особенности русского театра военных действий в своих планах. Например здесь https://logisticsmgepsupv.wordpress.com/2023/05/31/napoleons-logistics-the-art-of-sustaining-empires/
Казалось бы какой прекрасный мир, в котором все действия регламентированы. Т.е. разработаны алгоритмы буквально на всё. Включая обработку нештатных ситуаций. Но так не бывает, это иллюзия, разбивающаяся о реальность. Нарисовать всеобъемлющую инструкцию возможно только для полностью детерминированного мира. А в любом реальном есть взаимодействие с непредсказуемыми факторами. Можно конечно попробовать учесть их все, но как показывает практика оно либо не получается, либо инструкция распухает настолько что ей невозможно пользоваться. Но всё бы ничего, если это было бы единственной проблемой!
Номер два - ресурсы. Они всегда ограничены, поэтому их на всех не хватает. Ты можешь сколько угодно писать что должно быть сделано то-то и то-то, но когда у тебя некому или нечем это сделать.. А если это можно не делать или чем-то заменить, возникает вопрос - а правильно ли спроектирован процесс?
И переходим к самому интересному. Правила сами не соблюдаются. За ними нужно следить. И к тому же наказывать тех кто их не соблюдает. Чем больше правил - тем сложнее в них разбираться, тем больше контролёров нужно. Задача контролёра - не сделать хорошо, а сделать по инструкции. Это не из вредности, это by design. Поэтому начинает расти ком проблем - власть в карающем органе опьяняет, подловить на несоблюдении какой-либо инструкции можно любого. И неважно, есть тут злой умысел при административной борьбе, просто вредненький человек, или искренне хочет выполнять свою работу. Инструкции после определённого момента, по мере увеличения их количества, начинают не помогать, а вредить процессам, а увеличиваются они потому что толпа контролёров плодит и совершенствует инструкции до бесконечности, даже если сами понимают что некуда - ибо этим они поддерживают видимость своей работы и пользы.
И в результате благая идея заменяет полезную работу на соблюдение инструкций. Производительность падает, люди увольняются - те кто работать не хочет принимают правила игры и начинают использовать инструкции для обоснования ничегонеделанья, а кто хочет получают постоянные выговоры за их несоблюдение.
Но идёт это постепенно - поэтому это сложно заметить, долгое время руководство радуется как у нас всё гладенько и ровненько, пока не приводит к полной финансовой несостоятельности. Поздний СССР - все строго соблюдают миллион правил, поэтому стройки идут уже не годами, а десятилетиями, но зато всё по инструкции.
"Внедрение регламентов и инструкций сначала однозначно увеличивает эффективность работы, потом эффект становится разнонаправленным, но после какого-то момента начинается обратный процесс снижения эффективности, вплоть до драматичного."
Здесь есть несколько моментов.
Да, знать регламенты необходимо, потому что это помогает защитить себя. Без вариантов.
Нормативка на самом деле очень правильная вещь - я долгое время шарахался при слове ГОСТ, но погрузившись в тему понял насколько стандартизация полезная штука. В том числе когда компания создаёт внутренние "ГОСТы".
Беда начинается, когда к делу подходят комплексно и решают регламентировать всё что видят - тогда вместо регламентов помогающих работать появляются бесконечные тексты про то как надо содержать рабочее место, общаться с коллегами, проводить совещания, оформлять переписку... И главное само по себе оно может и неплохо - но как лавина погребает под собой всё разумное.
Как раз вчера обсуждал эту тему и набросал небольшую заметку по мотивам, может какие мысли будут интересны.
Проблема не в том что регламенты читать не хотят, а что любая уважающая себя компания плодит их быстрее чем успеваешь их читать :).
Вывод в "итого" абсолютно верный, хочу только отметить что когда регламенты читают исключительно для того, чтобы не подставляться, это очень хорошо характеризует эти самые регламенты. Значительная часть их написана не для организации работы, а для избегания ответственности, как табличка "купаться запрещено" - всем всё равно можно в этом месте на самом деле купаться или нет, а смысл её чтобы если я утону за это никто не отвечал.
И всё вернётся на круги своя. Исчезнут тысячи выпускников ит-курсов, в программирование будут идти только увлечённые люди. И - да, компании, которые захотят сохранить серьёзную ИТ-экспертизу, будут растить их у себя.
Прекрасная аналогия - можно развивать продукт, не экономя на проектировании, комплектухе, обслуживании, не лезть в "хакерские" схемы налогообложения - а можно "оптимизировать", впаривая потребителю ненадёжный, некачественный или вообще опасный продукт, и иметь наготове билет через Беларусь в Эмираты, чтобы попытаться успеть им воспользоваться когда налоговая наконец заметит эти шалости. Вот с IT - ровно то же самое.
Треугольник никто не отменял - чтобы сделать дёшево и качественно, требуются высококвалифицированные специалисты, чтобы понимать, где можно экономить а где не стоит. Вот только захотят ли они биться с "эффективными менеджерами" за каждый мегабайт оперативки?
А сеньоров будут выпускать "курсы по подготовке сеньоров"? Программист [если] становится сеньором, только пройдя весь путь от джуна, набравшись опыта и насобирав шишек.
Только нельзя забывать что эта красота не бесплатна - подробное описание задачи само по себе ресурсоёмко, чётко, коротко и ясно сформулировать не так просто. Поэтому важно контролировать баланс между потенциальными выгодами и потерями - насколько проблемы с потерей контекста обойдутся дороже чем ковровое документирование?
Я ни в коем разе не призываю к односложным тикетам для галочки, по которым вообще ничего не понятно, что и зачем нужно сделать, а исключительно обращать внимание на адекватность формализации, чтобы не организовать самим себе итальянскую забастовку.
А шаблоны заполнения тикетов - очень правильно.
На вопрос что такое успешный проект всегда хочется уточнить - "а для кого успешный"? Статья кратко намекает, что фактические критерии успешности не всегда совпадают с их формальным определением, но самое-то интересное - и что дальше, что с этим делать?
Я полностью поддерживаю тезис, что значительное количество пользовательских интерфейсов профессиональных приложений не от мира сего, "проектировались" теми кто имел очень смутное представление о выполняемых в приложении задачах, и представляют собой нагромождение кнопок, цифирок и менюшек. Иногда просто диву даёшься, это ж какое изменённое сознание надо иметь чтобы так неудобно сделать. С другой стороны, теперь проектированием занялись "профессиональные дизайнеры", и стало ещё хуже, появился "интуитивно понятный интерфейс" с большими кнопками, интервалами, управлением мышкой, скроллингом итп.
Дело не в том, простой интерфейс или сложный, а насколько он соответствует выполняемым задачам. Более того, в хорошо сделанном "сложном" интерфейсе работать быстрее и проще, но это требует обучения и тренировки. Банальные шорткаты абсолютно не интуитивны, но ускоряют работу в разы по сравнению с мышкой. Поэтому надо понимать, хочешь ты сократить усилия на обучение, или улучшить качество работы (ускорить, упростить, уменьшить ошибки, снизить утомляемость..).
При этом само собой необходимо оценивать, ради чего тратятся неслабые деньги - чтобы сотрудник выполнял больше полезной работы, или получил больше времени гонять чаи на кухне? При этом категорически поддерживаю замечание, что мнение пользователей системы обычно мало кого интересует ("менеджеры продают топам").
И ещё часто пишут о слишком больших издержках на кросс-коммуникацию между всеми участниками проекта, но почему-то одновременно поощряют их в "эджайл-стиле", называя это вовлечённостью в проект. Я считаю что сотрудники должны быть хоть и не изолированы от внешнего мира, но огорожены от внешних воздействий и непрерывной коммуникации со всеми подряд. (Особенно это пагубно, когда интроверты-разработчики сталкиваются с экстравертами-менеджерами). Это мало того что выбивает из рабочего ритма, так ещё и путает приоритеты исполнения. В таком случае руководитель не может нести ответственность за своевременное выполнение задач, и получается что "никто не виноват", только работа недоделана.
Понятие "лучше" не существует в отрыве от задач и исполнителей. Поэтому так часто проваливается попытка внедрения "лучших практик". Плюс важным фактором является представление о прекрасном высшего руководства, как оно считает "правильным", да и банально характеры сотрудников. Поэтому я бы ответил, что правильным является использование комбинированной структуры - но загвоздка в том, что как она должна выглядеть ответа нет. В качестве не часто упоминаемых, но на мой взгляд важнейших факторов, хотел бы отметить наличие персональной, а не коллективной ответственности за результат.
Мне кажется, что рациональная схема гибрида - это когда на базе функциональной структуры, с единой точкой входа задач в отдел, формируется проектная структура на уровне не рядовых сотрудников, а руководства подразделения. Т.е. все руководители отделов (или их замы, не суть), видят не отдельные сыплющиеся им на вход задачи, а весь жизненный цикл ведущихся проектов, имеют понимание об их объёмах и приоритетах, и уже в зависимости от этой картины приоритизируют задачи внутри отдела. А каждому проекту назначается проджект, который является фактически администратором.
В общем, тут можно теоретизировать до бесконечности, а потом выясняется что у тебя в "кросс-функциональной команде" то одни энергичные джуны, то мидлы работающие строго с 10 до 6, то сплошные сеньоры тянущие одеяло на себя :)
Статья как раз о том что административными мерами смысла бороться с совещаниями нет. Надо не их ограничивать, а процессы налаживать, ведь по факту совещание это костыль для процесса, когда требуется ручное управление. Моё ИМХО что если совещание меньше 15 минут, то вопрос можно по телефону обсудить, больше времени потратишь пока до переговорки дойдёшь.
Так можно и не 7 стратегий написать - только они все называются "найти уникальную фичу вашего бизнеса". И об этом говорят из каждого утюга про правильную рекламную стратегию. А одинаковые они получаются не потому что кто-то не знает этот секрет Полишинеля, а потому что разбираться с каждым, искать индивидуальный подход - это дорого, а надо чтобы быстро и дешево. Как у того юриста из примера.
Как эти методики оценки ни назови - они являются лишь различной обработкой экспертных цифр оценки. Которая выбирается в зависимости от того, какой из вариантов результата больше нравится оценивающему :)
У нас был "крутой" компьютерный класс - "цветных" ямах было штук 10, с одним дисководом, "учительская" с двумя, и ещё пачка чёрно-зелёных. Написал на бэйсике первую игрушку, с использованием спрайтов! Вообще машина по тем временам космос была, по сравнению с IBM PC - когда открыли новый класс с писюками, я поначалу был в шоке от убогих мониторов CGA и 5" дискет. После 256 цветной графики и 8 канальной музыки!
А в чём необходимость вообще обновляться на полюсе?? Без какой такой функциональности телефона Samsung нельзя обойтись до возвращения на большую землю?
И как учитывать такой момент, что люди будут стараться попасть в установленный срок, даже неосознанно. Если заложили многовато то станут более тщательно тестировать, делать код "получше", если маловато - то торопиться, местами откровенно тяп-ляп. В результате получается подгонка решения под ответ - оценка сроков будет "точная", а качество продукта при этом очень сильно плавать. Тогда planning pocker нужно применять и далее - чтобы исполнители не знали, какой реально срок был назначен :).
Кажется лёгкой цифра "фактическое время". А насколько она точна? Как выцепить время потраченное именно на реализацию данной фичи на фоне параллельно реализуемых задач? Например, реализация фичи по (консолидированной) оценке должна была занять 40 часов. А сделали её через месяц. Сколько времени из этого месяца занимались именно данной фичей, чтобы можно было понять, попали в оценку или нет?