Pull to refresh

Comments 72

Есть целая книга Ивана Бевуча "Пузыри" ))

Да, но я покупал электронный вариант книги https://бевуч.рф

Нет, но он уже собрал деньги. Сказал скоро издаст. Хотя, говорит, денег может и не хватить и ему прийдётся собирать их ещё раз.

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

Напоминает анекдот про то, как заработать миллион…

...
и издавая об этом книги и статьи!

Четыре человека за сутки прислали ссылку, поэтому даже пришлось зарегиться, чтобы внести ясность.
1. Книга издана. Деньги собрал на книгу тут: https://planeta.ru/campaigns/bubbles/updates. Собрал успешно 305к. По ссылке все новости сбора и издания.
2. Все потратил на выпуск + мерч в виде футболок, закладок и стикеров. Тираж: 200 физических экземпляров и где-то 200 электронных. По ссылке на планете фотки первых 49 обладателей физических книг.
3. Если кому интересно, то первые 30 страниц книги в электронном виде лежат у меня в тележеньке: https://t.me/ddsbvch/3310. Это сверстанное начало от типографии, которое я решил выложить.
4. Все донатеры (кроме трех тормозов, а также Маека, которого торможу уже я) уже стали счастливыми обладателями книг. Плюс несколько десятков распространил с рук. У меня еще осталась где-то одна коробка из 16, так что велкам.
5. 27 отзывов на книгу лежат на сайте: https://бевуч.рф/#reviews.
6. Варианты переиздания прорабатываются, но тоже за деньги, которых хз где взять.
Как это «200 электронных»? NFT-токены?
Не. В рамках сбора средств около 100 экземпляров было предзаказано. После окончания штук 20 подарил тем, кому хотел. Ну и где-то человек 50 пришло в личку уже после готовности книги. Плюс уже четверо пришло после этого комментария, хехе.
А электронные можно только через ЛС покупать? Не проще через магазин какой онлайн?
>6. Варианты переиздания прорабатываются, но тоже за деньги, которых хз где взять.

Подвешенное состояние. Опубликовать книгу в той версии, в которой она есть можно прямо сейчас в четырех магазинах, включая озон, литрес и букмейт.
Но если все-таки получится договориться с издательством, то гораздо правильнее прямо сейчас не вешать книгу в совсем уж общий доступ. Вот и жду. Если станет понятно, что точно нет, то опубликую.
Я понимаю, что много денег не бывает, но стоит ли продаваться диаволу, особенно в ситуации, когда есть другие варианты?
Четыре человека за сутки прислали ссылку, поэтому даже пришлось зарегиться.
1. Книга издана. Деньги собрал на книгу тут: https://planeta.ru/campaigns/bubbles/updates. Собрал успешно 305к. По ссылке все новости сбора и издания.
2. Все потратил на алкоголь и женщин выпуск + мерч в виде футболок, закладок и стикеров. Тираж: 200 физических экземпляров и где-то 200 электронных. По ссылке на планете фотки первых 49 обладателей физических книг.
3. Если кому интересно, то первые 30 страниц книги в электронном виде лежат у меня в тележеньке: https://t.me/ddsbvch/3310. Это сверстанное начало от типографии, которое я решил выложить.
4. Все донатеры (кроме трех тормозов, а также Маека, которого торможу уже я) уже стали счастливыми обладателями книг. Плюс несколько десятков распространил с рук. У меня еще осталась где-то одна коробка из 16, так что велкам.
5. 27 отзывов на книгу лежат на сайте: https://бевуч.рф/#reviews.
6. Варианты переиздания прорабатываются, но тоже за деньги, которых хз где взять.
Держу вполне себе изданную книгу в руках, могу прислать фото.
про внутреннюю автоматизацию можно по подробней?
а то я только понаставил датчиков, теперь непонятно кому это надо и зачем я это сделал и что дальше то делать?
Можно, тут либо вы должны быть CTO и тогда автоматизация, мониторинг, аналитика это просто ваша обязанность, либо вам нужно найти заинтересованного потребителя, хотя в первом случае тоже нужно но там его можно и создать.
Снимать показания с датчиков, высылать СМС'ки (Или писать в мессенджеры) заинтересованным людям (Отвечающим за объект/устройство/установку/отдел/и т.п.), когда что-то пойдет не так.
Подойти к тем, кто хотел эти датчики, и сказать «Поставил. Что дальше?». Если таковых нет и не было, то этот вопрос задается себе.
+ и со временем учишься задавать этот вопрос пораньше, до того как что-либо начал ставить.
Собирать данные и хранить в течение года-двух. Потом можно строить красивые графики) Как у Райкина: «Это в сравнении с 913м...»
Вот только вы зря вините программистов. В первом случае надувание со всех сторон идет от тех кто продал проект. Причем надувание не только пузырей. Далее идет PO, PM. От PO вообщи зависит почти все, но PO с готовым видением и бескомпромисным стремлением к созданию хорошего продукта пойди еще найди. PM сейчас в четырех случаях из 5 тоже в общем то занимаются какойто херней, но доказать свою полезность очень очень надо, даже если ты просто играешь в передаста. Потом идут аналитики, многих из которых в сию прекрасную пору «вошействия в айти» нужно выгонять на мороз за их бесполезность в половине случаев, ибо умных слов уже выучили, а собственно сама аналитика, разносторонний анализ, изучение крайних случаев, оформление своих мыслей человеческим языком — нет. Затем все это доблестно, весело, со всеми глюками вгружается в дизайнеров, которых по сути еще с первого дня трудоустройства нужно заставить пользоваться каждым своим интерефейсом, каждый гребаный день, а если там интерфейсы касс/станков то отправить именно туда, до просветления. Но нет, люди, за маковскими(или иными) высококонтрастными 27+ мониторами, по глюкам пришелдшим сверху и аналитике, которой грош цена, делают «интерфейсы» которыми их самих никогда не принудят пользоваться, сдабривая своими глюками и некомпетентностью. Ну и мы скромно забудем, что хорошие крутые дизайнеры — редкость, потому что нужно очень много знать о психологии, о цветах, формах, о технологиях. Ну и вот наконец мы добрались до, как вы говорите? «главные надуватели, программисты»? И что они в этой ситуации уже могут сделать? объяснить всей цепочке что они — идиоты? Поверьте, многие из них пытались, и не раз и не два и не десять. Но да, возможно вы прав и тут те же лоси которые пишут «высоконагруженые» (аж целых 3000 товаров у нас в интернет магазине!!! (с)) проекты всяких «интернет-магазинов» по 3 года.

Я в такую позицию попадал не единожды будучи тимлидом, но я — особый случай, потому что я эту вертикаль прошел уже сверху вниз и снизу вверх, в разных вариантах. И я человек, которому не плевать. И вот я как раз для надуватаелей — большая проблема. А у вас уже все написано и мне только реализовать? Тут и тут не продумано, тут — продумано плохо, тут — откровенная чушь. Подать мне PO, ему буду объяснять почему так делать нельзя и будем думать. Аналитиков и дизайнеров мне в подчинение, никаких параллельных отделов и людей не отвечающих ни за что. PM а зачем мне испорченный телефон между мной и PO? Либо под меня либо в параллель (под PO) и пусть помогает окучивать всех ЛПР (людей принимающих решения) и прочих потребителей продукта на стадиях предпроекта, проектирования и внедрения. Ну и конечно мы будем есть слоника по частям, ошибаясь и переделывая, оценивая что пошло не так (цикл Деминга, будь он неладен). Да, только так, нет я не буду делать то что написано, я не занимаюсь созданием дерьма.

Цикл Деминга -- это, кстати, то что потом "изобрели" в scrum и прочих agile ;)

Абсолютно точно. Мы однажды автоматизировали одну, средней руки, компанию в Канаде. Полностью, от внутреннего документооборота, CAD/CAE до производства(CAM) и складов. Так в результате 2-месячного ежедневнего квеста в попытках выяснить как всё работает сейчас и что требуется я выяснил, что лучшего всего внутренний документооборот знают две секретарши, две продажницы, CAD инфраструктуру — техник, который бегает туда-сюда между инженерами и цехом, ну а производство — неформальный лидер работяг, пожилой шриланкиец. Самое главное они все знали четко что им нужно от автоматизации с точностью до приоритетов. Двадцать человек менеджеров и боссов представляли себе работу компании с точностью до наооборот. Вот показания вышеописанных незначительных персон и были положены в основы первоначального ТЗ. Когда мы закончили правящая элита сказала нам, ну вот видите именно так я и говорил, очень гордились собой. Мораль — ищите тех кто знает.
Отличный сюжет для фильма. Даже не думал о том что работа аналитика похожа на расследование
Знакомо, ровно так же всегда делаю и не верю заказчику от слова совсем, ищу тех кто реально в курсе как обстоят дела. Плюс сам пробую работать на всех местах которые собираюсь автоматизировать. В остальном же — на этом приключения только начинаются, потому что проектировать интерфейсы для таких приложений действительно сложно, просить не у кого и хороших примеров почти нет (некоторые из моих компонентов как были 10 лет назад самые удобные так и остались).

Плюс веселье с интеграцией со всякой распространенной фигней. Например уже который раз ввязываюсь в «а давайте тесно интегрироваться с ЭДО», говорря «ребят, в РФ ЭДО — хрень, не надо даже тратить силы», не верим, пробуем, через полгода предсказуемо узнаем что ЭДО в РФ — полная херня. Или «зачем нам делать форму счета/упд в приложении, в 1с же все есть» — «господа, все же давайте не будем, в бухгалтерскую 1с передать данные проблем нет, но синхронизировать все сущности чревато проблемами с проведением» — ну ровно в это и впиливаемся)
Тут всё просто. Автор топит за Agile. А Agile — это по большей части на программистах всё. Вот он программистов крайними и делает.
PM сейчас в четырех случаях из 5 тоже в общем то занимаются какойто херней, но доказать свою полезность очень очень надо, даже если ты просто играешь в передаста.

image

А в каком аджайле одновременно есть и тим-лиды и РО?

В аджайле кровавого энтерпрайза бывает. Сам видел.
Задача PM как раз и быть передастом.
Простой, надёжной шиной передачи данных с конвертированием из бизнес-задач в ТЗ и обратно кода в решение оных задач.

Тогда это секретарь и пусть дует в подчинение к тимлиду. Project Manager это совершенно другое. Этот человек САМ может спрогнозировать сроки исходя из загрузки команды и управлять проектом, иначе слово менеджер тут знаете ли не при делах становится, а если он бегает к разработчиком с фразой "ну что когда" и "сколько это займет времени" то он нужен дляяяя? Самое смешное наступает, кстати, когда такой передаст выматываем всю душу из разработчиков а потом вместо того чтобы этой инфой ублажать тех кто над ним просто оставляет при себе. Сломанный телефон не нужен вообще никому. Ну а если вы настаиваете что PM секретарь то пусть бегает куда скажут, ну и зп естественно надо бы порезать.

Про внутреннюю автоматизацию — вот прям в точку.

Причем, что характерно, практически всегда срабатывает примета: если что-то предложишь (да что угодно полезное/доброе/вечное), значит теперь этого никогда у нас не будет. Я таким нехитрым способом зарубил на предприятии много хорошего.

После последнего случая метания бисера перед начальством — забил болт на создание таких «пузырей».

Теперь утром — техзадание, сроки, оплата. Вечером (на неделе / до конца месяца / до осени / когда-нибудь) — результат. В 90% случаях все заканчивается на техзадании. Не каждый начальник «долетит до середины» техзадания.
В 90% случаях все заканчивается на техзадании.

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

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

Так для этого как раз и нужен толковый аналитик - перевести с одного русского на другой.

Часто они не имеют на это лишнего рабочего времени.
А тратить свое личное время не хотят.
Не не могут, просто хотелка извлеченная из головы (в которой она живёт в виде эмоционального мыслеобраза) превращается в то чем она и является — малосвязанной абстрактной трухой.

На этом психотерапевтические практики работают, только вынимают из головы проблемные мысли после чего человек смотрит и говорит «и ЭТО было во мне!?». Помните, как в первой матрице извлекали из Нео жучка-паразита?
Когда-то в одной не маленькой организации делал я разную автоматизацию. Я программистом, глав.бух, и директора. Запустили с нуля управленческий баланс, себестоимость, и кучу всего на протяжении долгого времени. В среднем по ощущениям, из накоденного запускалось в жизнь не более 20%. Остальное подвисало неиспользуемое или вообще не доделанное. Конечно все это разрасталось и мешало новым планам, но суть не про это.

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

Следующая существенная причина не запусков, это то, что нет людей, которые могли бы заводить нужные данные. У меня уже давно привычка, что когда дают задачу требуемую пользовательского ввода, то всегда мой первый вопрос, «Кто это будет заводить? У него есть на это время?».

Сейчас, уже в другой, то же не маленькой организации, я по прежнему делаю разные автоматизации (надоело...). В среднем по ощущениям наблюдаю, что запускается в жизнь около 50% кодинга. Кусочек отмирает позже, по разным причинам. Основным отличием, что здесь крайне мало ситуаций, что прежняя задача подождет, а сейчас-теперь важнее другое. Но остался вопрос, «А кто это будет все заводить?», на который не всегда могут дать ответ, но говорят, что типа там разберемся.

Требовать что бы задачи всегда запускались в жизнь, это не возможно. Это так же как требовать от программиста, что бы всякая написанная им буква была нужна в последующем коде. Этого никак не сделать, это естественный процесс, попробовать-проверить, посмотреть что из этого получится. Если не пробовать, то вообще ничего не будет сделано. Если пробовать, то в любом случае будет часть решений ошибочных.
Я думаю, вам стоит поменять свою стратегию — те, кто ни… чего не понимают в автоматизации, ее возможностях и ограничениях, никогда не поставят вам задачу. Надо разобраться в том, что есть бизнес, и понять, что полезного для бизнеса вы можете сделать.
Ну почему же? Тут все замечательно. 50% и даже 20% это все лучше чем 0% при чистых пузырях.

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

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

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

Как подвид внутренней автоматизации, можно добавить про системы электронного документооборота (СЭД). На одной из моих предыдущих работ столкнулся с таким «супервнедрением». Проектом СЭД руководила нерадивый менеджер (очень скоро ее «ушли» из компании). В итоге получилась совершенно неюзабельная и непригодная к жизни система, которой попросту заставили пользоваться сотрудников, ибо продвигалось «улучшение» сверху.
Для примера основной и самый главный косяк, из-за которого моя работа вообще стала невыполнимой. В системе электронного документооборота невозможен полнотекстовый поиск. Как вы себе это представляете? А очень просто. Реализовали только поиск по номеру документа. Т.е. когда я создаю там документ, заполняю информацией, даю название, подставляю ключевых лиц, и т.д. — это все на экране текст. Но достаточно нажать кнопку «Сохранить» — все, пиши пропало. Документ создается в системе, ему присваивается индексный номер, а информация… Непонятно что происходит с ней, но когда открыть этот «документ» — он на экране отображается в виде картинки. С невыделяемым текстом. Просто картинка. К редактированию доступны лишь поля где будет идти дальнейшая работа с документом в процессе его движения. И если я через неделю захочу по тексту найти что-то из системы — не получится. Надо только знать номер документа и его указывать в поиске. Все.

С этим столкнулись и коллеги. А на все наши попытки доказать проджект менеджеру всю абсурдность ситуации и необходимость реализации поиска по словам в электронной системе, ведь все равно же оно в базе данных то наверное текстом хранится, что тут сложного — разбивались о полнейшее равнодушие и непонимание в духе:
— А зачем это вам нужно, вы что-то странное требуете. Поиск же работает (хоть и по номеру) — значит ТЗ реализовано. Искать по тексту система не будет — программисты уже написали так, и переделывать нерентабельно. Так что вы просто запоминайте номера и ищите по номерам. Ааа, у вас много документов — ну тогда ведите себе ексельку, где храните названия и номера документов, и оттуда подставляйте в систему для поиска. Что, вам это не подходит? Ну значит вы неправильно работаете с документами, вам нужно полностью перерабатывать ваш бизнес-процесс и подход к документообороту.

Не менее абсурдно реализован и вывод на печать. Поскольку никакой возможности выделить текст чтобы распечатать выделенное, или скопировать текст (или хотя бы тот горе рисунок с текстом), и распечатать из буфера — тоже невозможно, остается только пользоваться внутренней единственной кнопкой «Распечатать» из этой СЭД. Но и здесь весело. Ни единой настройки или диалога печати нет. Содержимое документа по нажатию кнопки выводится на бумагу «как системе угодно», с кучей ненужных пустых полей по бокам, сам же текст где-то в углу листа.
Единственное, на что тут удалось повлиять — кнопку печати добавили везде. Потому что изначально она даже не везде была доступна. На определенных видах документов (причем самое частое используемых) просто отсутствовала. Тут послушались, кнопку добавили. Но никаких изменений или улучшений этой «распечатки» тоже не дождались.

Возражения — аналогичные как при встрече и беседе по багах поиска.
— А зачем вы вообще печатаете? Это же электронный документооборот! Вам вообще бумага теперь не нужна, проводите все согласования и подписи через наш корпоративный СЭД. Для этого в него и вбухали денег и реализовали. Что? Вам нужно распечатывать, чтобы хранить копии документов у себя в шкафу, потому что в СЭД не работает поиск? Вы неправильно работаете.

Итоги печальные. Проработав еще несколько месяцев там и видя полнейшую бесперспективность, ушел (не из-за самой СЭД, просто это было одной из капель в чашу остальных проблем). Что стало с системой в дальнейшем не знаю. Но имея опыт успешной работы с другими СЭД, где все с этим делом обстоит прекрасно (любые поиски как душе угодно, фильтры, запросы, всевозможные виды печати и т.д.) — могу назвать ту СЭД как раз по теме статьи, большим мыльным пузырем автоматизации.
Вы могли сделать только одно — отказаться работать в этой программе. Если, однако, даже с такими ограничениями для вас получался полезный результат — грех жаловаться. Если полезный результат был у других пользователей, а у вас дополнительные затраты — жаловаться тоже, в общем, грех, но попросить дополнительные ресурсы имело смысл.
Вместе с тем, тему повсеместного наплевательства на нужды исполнителей считаю раскрытой.
Учитывая перевод на данную систему всей огромной компании, лично я один отказаться не мог. Это значит подписать уход. Потому что надо было взаимодействовать по процессам с другими людьми. Которые так же мучились и не могли нормально пользоваться. Полезного результата не было, только проблемы. Хотя возможно при толковом ПМ и реализация системы была бы совершенно иной.
Я хочу вас поддержать, т.к. наблюдаю пренебрежение многих людей к такой фундаментальной вещи как полезность результата труда для других людей.

Ведь эта вещь лежит на поверхности и является неденежным мотиватором для огромного количества программеров, которые пишут опенсорц. Мы — стайные существа и мы самой эволюцией запрограммированы испытывать счастье и благодарность когда оказываемся полезными другим или делаем что-то, что оказывается полезным для других.
Вероятно это была 1с. В 1с документы не сохраняются в виде картинки. Вероятно в формах доков использовали «Доступность = Ложь» вместо «ТолькоПросмотр = Истина». Но это не имеет отношение к полнотекстовому поиску, который кстати то же парой галочек настраивается. В общем кучка технических косяков, не имеющих отношение к общему вектору проекта. Вероятно кроме менеджера там был еще и программист не очень, потому что в мелочах удобство пользования закладывается программистом.
Нет не 1С точно, то знаю, да и интерфейс совершенно иной :-)
Что-то редкое, до этого не слышал, и сейчас уже не помню названия, там все в зеленых тонах.
Вот нашел картинку отдаленно напоминающую общий вид:
Заголовок спойлера

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

Но это не точно.

Картинки не учили в спойлер убирать?

Чтобы не получать огромных пузырей надо отстаивать позицию, что проекты более 3 месяцев не подойдут под waterfall. Сначала бы сделать mvp, а потом уже смотреть куда двигаться.
А еще бывает внедрение безо всякой методологии, просто одиозный IT-директор забалтывает наблюдательный совет и внедряет всякое, что потом лет 10 не могут разгрести.
Если слово «программисты» заменить на любых других реализаторов галлюцинаций менеджмента, то в сути статьи не поменяется ничего. Так стоит ли выносить в заголовок программистов?
Довольно странный посыл в статье. Обстоятельно и многословно рассказывается о том как проект разрабатывается, со всеми факапами на каждом этапе, с массой некомпетентных людей с полномочиями, которые пытаются совместно родить какую-то неведомую хрень, и в итоге во всем виноватыми оказываются программисты, которым выдали на руки ТЗ, и которым платят за то что они пишут код, который это ТЗ реализовывает.
Это все равно что обвинять каменщиков в том, что они сложили по проекту, утвержденному заказчиком, одноэтажный особняк, когда заказчик хотел небоскреб, но в процессе создания проекта все пошло куда-то не туда и он согласился на одноэтажный дом.
Возможности программистов не идут дальше ТЗ. Дали тебе кривой ТЗ, это да, тут можно поднять шум и добиться того что-бы тебе нормально поставили задачу, но если оно сделано более-менее корректно — программисты не телепаты и не прорицатели, они не могут знать что там на самом деле хотел заказчик и что в итоге он будет использовать.
Тема в том, что ИТ и автоматизация окончательно (но, надеюсь, не бесповоротно) разделились. Мы живём в абсурде. Ноша сия велика есть, и хорошо, что программисты это приблизительно понимают (пусть и не до конца).
В каком смысле разделились? Автоматизация это только инфоцыгане?
Помогаю разрабатывать проекты.
Хочу отметить иногда эго, пофигизм и непрофессионализм.

1. Product Owner (PO) пытается реализовать идею, но зачастую не общается с пользователями и фантазирует фишки. Эго — я сам все знаю.
2. Программисты требуют жесткий тз. В реальном мире PO невозможно заранее описать задачу в деталях. Программисты часто видят ошибки PO, но просто делают что сказали. Пофигизм.
3. PO, PM, Team Lead, Dev часто непрофессионально решают сложности (конфликты) и проекты заходят в тупик.
Для успешной разработки иногда нужно работать командой в большом зале и буквально подходить друг к другу за разъяснениями. Рисовать на доске, прототипировать.
Желательно частое общение, тесная работа с PO и пользователями, понимание продукта.
Важно брать инициативу и организовывать частые демки PO и юзерам.
Как-то так.
2. Программисты требуют жесткий тз. В реальном мире PO невозможно заранее описать задачу в деталях. Программисты часто видят ошибки PO, но просто делают что сказали. Пофигизм.

Программисты очень часто оказываются в самом конце списка, им задача сваливается «сверху», и зачастую на этом уровне невозможно понять — это тупо, или нормально, просто ты что-то не до конца понимаешь. А РО где-то там в высших сферах вращается, до простых лягушек не снисходит, вот и получается — дали бредовую задачу — ну «нате вам» реализацию.

Пофигизм рождается от отстраненности, сначала сделали из программистов взаимозаменяемых мартышек на конвейере, которые просто должны крутить гайки весь спринт и максимум свободы маневра для которых — это выбор следующей задачи, из пары-тройки вариантов, а потом удивляются откуда этот пофигизм и выгорания.
2. Программисты требуют жесткий тз. В реальном мире PO невозможно заранее описать задачу в деталях. Программисты часто видят ошибки PO, но просто делают что сказали. Пофигизм.
Ну вот я всё время уточнял и добавлял примечания в стиле «мы это уже делали, получилось очень плохо, вот такие-вот проблемы появлялись», «тут конфликт логики, заключается вот в этом вот», «это не так просто, как кажется, поддержка будет требовать огромных ресурсов» и многие другие. Сначала работало, потом часть руководства была изменена и начались ответы «мы всё уже решили, твоё мнение не интересует». Последующие мои слова в ответ рассматривались как подозрение на неподчинение, развязывание конфликта и некомпетентность.

Так о чем речь, если само руководство (не из программистов) считает себя технически более грамотным? Дело не в пофигизме разработчиков (как минимум не полностью).

UPD: Ошибся веткой, ответ был для vagon333.
Думаю пофигизм тоже имеет место быть, но он зачастую возникает как следствие описанного вами: «мы всё уже решили, твоё мнение не интересует». Причем прямым текстом такое говорят не часто (мыжведь передовая компания, не надо всякой такой токсичности!), просто оно всем рабочим процессом подразумевается.

Программист стоит в самом низу пищевой цепочки, где-то там высокоумные дяди и тети что-то между собой решают, и вниз падают какашки ТЗ, которые программерам остается только исполнять как написано. Да и временные рамки обычно ставятся такие, что тупо нету времени что-бы досконально разобраться в проблеме. Некогда! Надо кучу задач решить, плюс исполнять ритуальные танцы у костра скрамить, готовится к демо, разгребать массу околопрограммистских задач (всякие там тикеты двигать, таймшиты писать, отчеты, кодревью и проч., проч), конвейер ждать не будет, пока ты там разберешься, да и нехрен — умные дяди и тети и так уже все переварили… (см. выше)
Это лучшая статья за 14 лет которую я видел на хабре….
Каких-то неправильных программистов Вы описали, или я не понял сарказма.
Если это только программисты, «гребцы на галере», то откуда им знать что плывем не туда? Где же были все ПМы, аналитики, руководители, «занятые пользователи», когда надували пузыри и делали не то что нужно? Не вижу здесь вины программистов в таком случае.
Если программисты были в курсе, что пишут не то что нужно и молчали при этом, то это — паразиты, и гнать их в шею.

Статья выглядит как обидка автора на программистов, или просто для хайпа и комментов.
Если программисты были в курсе, и вы прогоните их «в шею», то имеете шанс остаться вообще без программистов, учитывая маленькую вилку ЗП. Если программисты получали достаточно много по рынку, и мы доказали что они были в курсе, то Вы конечно правы.
Я привел такой пример с «вредителями» в качестве исключения, жаль что такие остались. Все же лучше их гнать если это было намерено или человек не исправился, не мешать т.н. естественному отбору.
Разве компании не жалко денег на их даже маленькую ЗП за тот вред и пользу которую они приносят?
А как поступать с аналитиками и остальными в таких случаях?

Прочитал пол статьи, уже знал, кто автор. Узнаваемый стиль.

Отвечая на последние несколько комментариев, замечу, что на уровне программистов встречаются чистые пузыри, к которым вся предыдущая цепочка может быть непричастна. Это оверинжиниринг. Немного гипертрофированный - см. Hello world от сеньор-разработчика.

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

Не всегда гоните на ПМ\TM. Многие хотят видеть ПO/ПМ/ТМ в одном человеке и желательно за самую низкую зарплату. В итоге когда идет разговор с владельцем:
В-Хочу фичу такую и такую
ПМ-Ок, сделать не проблема. Для чего она вообще будет нужна?
В-У всех есть и я хочу.
ПМ-Но зачем? Кто из пользователей просил или когда она будет использоватся?
В-Молчать и делать!
Sign up to leave a comment.

Articles