Комментарии 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. Варианты переиздания прорабатываются, но тоже за деньги, которых хз где взять.
Подвешенное состояние. Опубликовать книгу в той версии, в которой она есть можно прямо сейчас в четырех магазинах, включая озон, литрес и букмейт.
Но если все-таки получится договориться с издательством, то гораздо правильнее прямо сейчас не вешать книгу в совсем уж общий доступ. Вот и жду. Если станет понятно, что точно нет, то опубликую.
1. Книга издана. Деньги собрал на книгу тут: https://planeta.ru/campaigns/bubbles/updates. Собрал успешно 305к. По ссылке все новости сбора и издания.
2. Все потратил на
3. Если кому интересно, то первые 30 страниц книги в электронном виде лежат у меня в тележеньке: https://t.me/ddsbvch/3310. Это сверстанное начало от типографии, которое я решил выложить.
4. Все донатеры (кроме трех тормозов, а также Маека, которого торможу уже я) уже стали счастливыми обладателями книг. Плюс несколько десятков распространил с рук. У меня еще осталась где-то одна коробка из 16, так что велкам.
5. 27 отзывов на книгу лежат на сайте: https://бевуч.рф/#reviews.
6. Варианты переиздания прорабатываются, но тоже за деньги, которых хз где взять.
а то я только понаставил датчиков, теперь непонятно кому это надо и зачем я это сделал и что дальше то делать?
Я в такую позицию попадал не единожды будучи тимлидом, но я — особый случай, потому что я эту вертикаль прошел уже сверху вниз и снизу вверх, в разных вариантах. И я человек, которому не плевать. И вот я как раз для надуватаелей — большая проблема. А у вас уже все написано и мне только реализовать? Тут и тут не продумано, тут — продумано плохо, тут — откровенная чушь. Подать мне PO, ему буду объяснять почему так делать нельзя и будем думать. Аналитиков и дизайнеров мне в подчинение, никаких параллельных отделов и людей не отвечающих ни за что. PM а зачем мне испорченный телефон между мной и PO? Либо под меня либо в параллель (под PO) и пусть помогает окучивать всех ЛПР (людей принимающих решения) и прочих потребителей продукта на стадиях предпроекта, проектирования и внедрения. Ну и конечно мы будем есть слоника по частям, ошибаясь и переделывая, оценивая что пошло не так (цикл Деминга, будь он неладен). Да, только так, нет я не буду делать то что написано, я не занимаюсь созданием дерьма.
Цикл Деминга -- это, кстати, то что потом "изобрели" в scrum и прочих agile ;)
Плюс веселье с интеграцией со всякой распространенной фигней. Например уже который раз ввязываюсь в «а давайте тесно интегрироваться с ЭДО», говорря «ребят, в РФ ЭДО — хрень, не надо даже тратить силы», не верим, пробуем, через полгода предсказуемо узнаем что ЭДО в РФ — полная херня. Или «зачем нам делать форму счета/упд в приложении, в 1с же все есть» — «господа, все же давайте не будем, в бухгалтерскую 1с передать данные проблем нет, но синхронизировать все сущности чревато проблемами с проведением» — ну ровно в это и впиливаемся)
PM сейчас в четырех случаях из 5 тоже в общем то занимаются какойто херней, но доказать свою полезность очень очень надо, даже если ты просто играешь в передаста.
А в каком аджайле одновременно есть и тим-лиды и РО?
Простой, надёжной шиной передачи данных с конвертированием из бизнес-задач в ТЗ и обратно кода в решение оных задач.
Тогда это секретарь и пусть дует в подчинение к тимлиду. Project Manager это совершенно другое. Этот человек САМ может спрогнозировать сроки исходя из загрузки команды и управлять проектом, иначе слово менеджер тут знаете ли не при делах становится, а если он бегает к разработчиком с фразой "ну что когда" и "сколько это займет времени" то он нужен дляяяя? Самое смешное наступает, кстати, когда такой передаст выматываем всю душу из разработчиков а потом вместо того чтобы этой инфой ублажать тех кто над ним просто оставляет при себе. Сломанный телефон не нужен вообще никому. Ну а если вы настаиваете что PM секретарь то пусть бегает куда скажут, ну и зп естественно надо бы порезать.
Причем, что характерно, практически всегда срабатывает примета: если что-то предложишь (да что угодно полезное/доброе/вечное), значит теперь этого никогда у нас не будет. Я таким нехитрым способом зарубил на предприятии много хорошего.
После последнего случая метания бисера перед начальством — забил болт на создание таких «пузырей».
Теперь утром — техзадание, сроки, оплата. Вечером (на неделе / до конца месяца / до осени / когда-нибудь) — результат. В 90% случаях все заканчивается на техзадании. Не каждый начальник «долетит до середины» техзадания.
В 90% случаях все заканчивается на техзадании.
Это точно. Иногда просто поражаешься, сколько людей банально не могут свои хотелки выразить в четких формулировках на бумаге.
Это точно. Иногда просто поражаешься, сколько людей банально не могут свои хотелки выразить в четких формулировках на бумаге.
Так для этого как раз и нужен толковый аналитик - перевести с одного русского на другой.
А тратить свое личное время не хотят.
На этом психотерапевтические практики работают, только вынимают из головы проблемные мысли после чего человек смотрит и говорит «и ЭТО было во мне!?». Помните, как в первой матрице извлекали из Нео жучка-паразита?
Половина причин, по которым не запускалось, это то, что прежде чем это успевало заработать, в головы руководителей приходила новая мысль, что именно сейчас нужно не то, что делалаось последний месяц, а вот новая какая-то фиговина, которую то же не меньше месяца делать. Прежняя мысль, они говорили, это то же нужно, но оно подождет. Так же как и пред-прежняя, и пред-пред-прежняя, и…
Следующая существенная причина не запусков, это то, что нет людей, которые могли бы заводить нужные данные. У меня уже давно привычка, что когда дают задачу требуемую пользовательского ввода, то всегда мой первый вопрос, «Кто это будет заводить? У него есть на это время?».
Сейчас, уже в другой, то же не маленькой организации, я по прежнему делаю разные автоматизации (надоело...). В среднем по ощущениям наблюдаю, что запускается в жизнь около 50% кодинга. Кусочек отмирает позже, по разным причинам. Основным отличием, что здесь крайне мало ситуаций, что прежняя задача подождет, а сейчас-теперь важнее другое. Но остался вопрос, «А кто это будет все заводить?», на который не всегда могут дать ответ, но говорят, что типа там разберемся.
Требовать что бы задачи всегда запускались в жизнь, это не возможно. Это так же как требовать от программиста, что бы всякая написанная им буква была нужна в последующем коде. Этого никак не сделать, это естественный процесс, попробовать-проверить, посмотреть что из этого получится. Если не пробовать, то вообще ничего не будет сделано. Если пробовать, то в любом случае будет часть решений ошибочных.
Как по Вашему, если взять крупного-крутого автоматизатора типа ПервыйБит, сколько процентов их кодинга запускается в жизнь? Как и у меня, часть отмирает до запуска на переобсуждениях, часть после запуска. Но в отличии от них, я имею возможность наблюдать, как это живет дальше. Чем дольше общаешься с организацией, тем лучше ее понимаешь, тем более полезные вещи там можешь делать.
Единственно, это мешает карьерному/денежному росту, т.к. одна организация, как бы ты не был там полезен, не будет заметно повышать оплату. При этом небольшие редкие повышения сопровождаются большими скрипами и ахами, и деланьем вида, что этот человек теперь здесь всем должен и больше всех должен работать.
Обвинять их в каких-то глобальных косяках (как некоторые любят, перекладывать на них ответственность за бизнес) — такое себе занятие…
Как подвид внутренней автоматизации, можно добавить про системы электронного документооборота (СЭД). На одной из моих предыдущих работ столкнулся с таким «супервнедрением». Проектом СЭД руководила нерадивый менеджер (очень скоро ее «ушли» из компании). В итоге получилась совершенно неюзабельная и непригодная к жизни система, которой попросту заставили пользоваться сотрудников, ибо продвигалось «улучшение» сверху.
Для примера основной и самый главный косяк, из-за которого моя работа вообще стала невыполнимой. В системе электронного документооборота невозможен полнотекстовый поиск. Как вы себе это представляете? А очень просто. Реализовали только поиск по номеру документа. Т.е. когда я создаю там документ, заполняю информацией, даю название, подставляю ключевых лиц, и т.д. — это все на экране текст. Но достаточно нажать кнопку «Сохранить» — все, пиши пропало. Документ создается в системе, ему присваивается индексный номер, а информация… Непонятно что происходит с ней, но когда открыть этот «документ» — он на экране отображается в виде картинки. С невыделяемым текстом. Просто картинка. К редактированию доступны лишь поля где будет идти дальнейшая работа с документом в процессе его движения. И если я через неделю захочу по тексту найти что-то из системы — не получится. Надо только знать номер документа и его указывать в поиске. Все.
С этим столкнулись и коллеги. А на все наши попытки доказать проджект менеджеру всю абсурдность ситуации и необходимость реализации поиска по словам в электронной системе, ведь все равно же оно в базе данных то наверное текстом хранится, что тут сложного — разбивались о полнейшее равнодушие и непонимание в духе:
— А зачем это вам нужно, вы что-то странное требуете. Поиск же работает (хоть и по номеру) — значит ТЗ реализовано. Искать по тексту система не будет — программисты уже написали так, и переделывать нерентабельно. Так что вы просто запоминайте номера и ищите по номерам. Ааа, у вас много документов — ну тогда ведите себе ексельку, где храните названия и номера документов, и оттуда подставляйте в систему для поиска. Что, вам это не подходит? Ну значит вы неправильно работаете с документами, вам нужно полностью перерабатывать ваш бизнес-процесс и подход к документообороту.
Не менее абсурдно реализован и вывод на печать. Поскольку никакой возможности выделить текст чтобы распечатать выделенное, или скопировать текст (или хотя бы тот горе рисунок с текстом), и распечатать из буфера — тоже невозможно, остается только пользоваться внутренней единственной кнопкой «Распечатать» из этой СЭД. Но и здесь весело. Ни единой настройки или диалога печати нет. Содержимое документа по нажатию кнопки выводится на бумагу «как системе угодно», с кучей ненужных пустых полей по бокам, сам же текст где-то в углу листа.
Единственное, на что тут удалось повлиять — кнопку печати добавили везде. Потому что изначально она даже не везде была доступна. На определенных видах документов (причем самое частое используемых) просто отсутствовала. Тут послушались, кнопку добавили. Но никаких изменений или улучшений этой «распечатки» тоже не дождались.
Возражения — аналогичные как при встрече и беседе по багах поиска.
— А зачем вы вообще печатаете? Это же электронный документооборот! Вам вообще бумага теперь не нужна, проводите все согласования и подписи через наш корпоративный СЭД. Для этого в него и вбухали денег и реализовали. Что? Вам нужно распечатывать, чтобы хранить копии документов у себя в шкафу, потому что в СЭД не работает поиск? Вы неправильно работаете.
Итоги печальные. Проработав еще несколько месяцев там и видя полнейшую бесперспективность, ушел (не из-за самой СЭД, просто это было одной из капель в чашу остальных проблем). Что стало с системой в дальнейшем не знаю. Но имея опыт успешной работы с другими СЭД, где все с этим делом обстоит прекрасно (любые поиски как душе угодно, фильтры, запросы, всевозможные виды печати и т.д.) — могу назвать ту СЭД как раз по теме статьи, большим мыльным пузырем автоматизации.
Вместе с тем, тему повсеместного наплевательства на нужды исполнителей считаю раскрытой.
Ведь эта вещь лежит на поверхности и является неденежным мотиватором для огромного количества программеров, которые пишут опенсорц. Мы — стайные существа и мы самой эволюцией запрограммированы испытывать счастье и благодарность когда оказываемся полезными другим или делаем что-то, что оказывается полезным для других.
Что-то редкое, до этого не слышал, и сейчас уже не помню названия, там все в зеленых тонах.
Но это не точно.
Это все равно что обвинять каменщиков в том, что они сложили по проекту, утвержденному заказчиком, одноэтажный особняк, когда заказчик хотел небоскреб, но в процессе создания проекта все пошло куда-то не туда и он согласился на одноэтажный дом.
Возможности программистов не идут дальше ТЗ. Дали тебе кривой ТЗ, это да, тут можно поднять шум и добиться того что-бы тебе нормально поставили задачу, но если оно сделано более-менее корректно — программисты не телепаты и не прорицатели, они не могут знать что там на самом деле хотел заказчик и что в итоге он будет использовать.
Хочу отметить иногда эго, пофигизм и непрофессионализм.
1. Product Owner (PO) пытается реализовать идею, но зачастую не общается с пользователями и фантазирует фишки. Эго — я сам все знаю.
2. Программисты требуют жесткий тз. В реальном мире PO невозможно заранее описать задачу в деталях. Программисты часто видят ошибки PO, но просто делают что сказали. Пофигизм.
3. PO, PM, Team Lead, Dev часто непрофессионально решают сложности (конфликты) и проекты заходят в тупик.
Для успешной разработки иногда нужно работать командой в большом зале и буквально подходить друг к другу за разъяснениями. Рисовать на доске, прототипировать.
Желательно частое общение, тесная работа с PO и пользователями, понимание продукта.
Важно брать инициативу и организовывать частые демки PO и юзерам.
Как-то так.
2. Программисты требуют жесткий тз. В реальном мире PO невозможно заранее описать задачу в деталях. Программисты часто видят ошибки PO, но просто делают что сказали. Пофигизм.
Программисты очень часто оказываются в самом конце списка, им задача сваливается «сверху», и зачастую на этом уровне невозможно понять — это тупо, или нормально, просто ты что-то не до конца понимаешь. А РО где-то там в высших сферах вращается, до простых лягушек не снисходит, вот и получается — дали бредовую задачу — ну «нате вам» реализацию.
Пофигизм рождается от отстраненности, сначала сделали из программистов взаимозаменяемых мартышек на конвейере, которые просто должны крутить гайки весь спринт и максимум свободы маневра для которых — это выбор следующей задачи, из пары-тройки вариантов, а потом удивляются откуда этот пофигизм и выгорания.
2. Программисты требуют жесткий тз. В реальном мире PO невозможно заранее описать задачу в деталях. Программисты часто видят ошибки PO, но просто делают что сказали. Пофигизм.Ну вот я всё время уточнял и добавлял примечания в стиле «мы это уже делали, получилось очень плохо, вот такие-вот проблемы появлялись», «тут конфликт логики, заключается вот в этом вот», «это не так просто, как кажется, поддержка будет требовать огромных ресурсов» и многие другие. Сначала работало, потом часть руководства была изменена и начались ответы «мы всё уже решили, твоё мнение не интересует». Последующие мои слова в ответ рассматривались как подозрение на неподчинение, развязывание конфликта и некомпетентность.
Так о чем речь, если само руководство (не из программистов) считает себя технически более грамотным? Дело не в пофигизме разработчиков (как минимум не полностью).
UPD: Ошибся веткой, ответ был для vagon333.
Программист стоит в самом низу пищевой цепочки, где-то там высокоумные дяди и тети что-то между собой решают, и вниз падают
Если это только программисты, «гребцы на галере», то откуда им знать что плывем не туда? Где же были все ПМы, аналитики, руководители, «занятые пользователи», когда надували пузыри и делали не то что нужно? Не вижу здесь вины программистов в таком случае.
Если программисты были в курсе, что пишут не то что нужно и молчали при этом, то это — паразиты, и гнать их в шею.
Статья выглядит как обидка автора на программистов, или просто для хайпа и комментов.
Разве компании не жалко денег на их даже маленькую ЗП за тот вред и пользу которую они приносят?
А как поступать с аналитиками и остальными в таких случаях?
Прочитал пол статьи, уже знал, кто автор. Узнаваемый стиль.
Отвечая на последние несколько комментариев, замечу, что на уровне программистов встречаются чистые пузыри, к которым вся предыдущая цепочка может быть непричастна. Это оверинжиниринг. Немного гипертрофированный - см. Hello world от сеньор-разработчика.
Ну а по поводу собственных инициированных пузырей, могу пример привести - в своё время написал модуль, вокруг которого построили целую серию совершенно разнообразных продуктов. Со временем, этот модуль развился, оброс кучей плагинов, просто потому что для существовавшего контингента программистов он закрывал вопрос взаимодействия крайних звеньев в трёхзвенном приложении. Правда, как итог, мало кто разбирался в том, как работает этот модуль, это конечно подогревает самооценку (многие приходили консультироваться, приходилось даже лекции читать, плюс, придуманный на коленке протокол повлиял на апи пары сторонних систем, с которыми интегрировались), но с точки зрения компании, мой уход стал проблемой.
В-Хочу фичу такую и такую
ПМ-Ок, сделать не проблема. Для чего она вообще будет нужна?
В-У всех есть и я хочу.
ПМ-Но зачем? Кто из пользователей просил или когда она будет использоватся?
В-Молчать и делать!
Надували, надуваем и будем надувать. Пузыри программистов