Итак, я зашел в раздел с постами и там увидел диаграмму (пик рилейтед).
А под ней ссылка на статью «Разработчики - в стойло, менеджеры в - башню из слоновой кости: создаем касту избранных в 4 шага».
Всего 3 комментария, 1900 просмотров и целых 37 пальцев вверх. Отличный результат, я уверен, тут нет никакой накрутки. Статья очень нажористая, рекомендую ознакомиться.
Нукси (имя изменено) поведала нам, как в отделе занимающемся дашбордом, где в отделе из 10 человек четверо менеджеры, перестать иметь хоть что-то общее с разработкой и преподать это как улучшение.
Из оригинальной статьи создается впечатление, что эти 4 менеджера управляют галактикой, но на самом деле, просто устраиваются поудобнее.
Уничтожаем экспертизу
Пт. От многофункциональных сотрудников — к профильным
Проблема:
...Сбор информации о клиентах, услугах, потреблении и оплатах производился разными системами, данные агрегировались в таблицах с разными структурами, не связанными общими признаками и логикой. В этих проектах для правильной и полезной аналитики иногда приходилось объединять разные вселенные.
Иными словами, для работы нужны сотрудники понимающие смежные предметные области, что не удивительно, если мы имеем дело с анализом данных.
Решение:
...Основная задача разделения заключалась в том, чтобы разработчики концентрировались на создании отчетов и обеспечивали непрерывный поток результативной работы, а методологи общались с заказчиками, собирали ТЗ для разработчиков…
...Это позволило нам не распыляться в многозадачности, а сфокусироваться на своем направлении.
Я прочитал только первый абзац и уже не могу.
В постановке проблемы вы написали, что для работы требуются эрудированные сотрудники, знакомые со множеством деталей из разных предметных областей, и сами же разделяете ответственность таким образом, чтобы сузить понимание смежных областей до минимума.
Теперь, отношения в отделе строятся не в горизонтальной, а в вертикальной плоскости. Менеджеры скидываю ТЗ вниз, а разработчики выполняют то, что им написали.
На основе ваших же слов, Нукси, вы не только не смогли найти в текущем подходе проблему, вы сразу перешли к подрывной деятельности.
Все должны быть виноваты
Пт. Определяемся с зонами ответственности и визуализируем бизнес-процессы
Поскольку задачи между аналитиками даже в двух разных командах концептуально пересекаются, перед нами встала следующая проблема. Не всегда было ясно, кто и за что должен отвечать. Например, кто отвечает за корректность данных? Методолог, который выпускает дашборд, разработчик, которые оперирует этими данными, или инженер базы данных, который организовывает сбор данных. Вы можете сказать, что это очевидно. Но, как показала наша практика, у каждого специалиста может быть свое мнение на этот счет.
Теперь менеджеры скидывают ТЗ вниз, но теперь разработчики просят внести правки в ТЗ прямо во время спринта. Во время написания кода, декомпозиции предметной области, всплывают недочеты. Непорядок, давайте это исправим.
...Нам было важно сделать так, чтобы ответ был одинаково очевиден для каждого участника процесса. Только так мы могли обеспечить качественное выполнение проектов в срок.
То есть пошел поиск виновных и принуждение через вину.
Смысл в том, что путем сложных согласований и выкручивания рук добиться от коллег письменного или устного «Да» под проектом.
Разные менеджеры используют разное напряжение и модели паяльников, но результат один.
Нужно заставить всех согласиться с выполнением именно этой версии проекта. Далее, если проблемы с ним таки всплывут, апеллировать к тому, что под ним все подписались. Ты же подставишь команду?
Это классический трюк ленивого менеджмента, он работает не только с коллегами, но и с заказчиками, они же подписались. Решение было принято, подписи сделаны, печати поставлены.
Как выкручивание рук работает в Selectel
Для обеспечения прозрачности мы подробно прописали бизнес-процессы в команде по ролям: кто и что делает на определенном этапе, какой ожидается результат.
Далее приложена диаграмма, которая меня заинтересовала с самого начала. На ней менеджер вместе с заказчиком проектируют решение в течение двух недель. Разве это не прекрасно?
Схема отличная и рабочая, если клиенты имеют понятие что конкретно они хотят и знают, как это донести до менеджера, если менеджеры имеют понятие о разработке и понимают клиента, а разработчики имеют понятие, что имеют в виду менеджеры.
(То есть, схема не рабочая)
Хайндсайт 20/20
После составления схемы выше, у менеджера случился хайндсайт 20/20 и ему пришло в голову еще 3 гениальные мысли. И со всеми этими мыслями у меня непонятки.
Невозможно измерить несуществующее
1.Не хватает планирования загрузки, задачи распределяются стихийно
Чтобы примерно прикинуть длительность разработки, можно сесть за стол с блокнотом и подумать.
Разбить проект на задачи, из опыта прикинуть, сколько времени уйдет на решение каждой из них и выдать DateTime[] в виде кривой нормального распределения, с разбросом оценок от месяца до полугода.
Нормальному менеджеру такой ответ не понравится, он с красными глазами будет на вас грозно смотреть, бить копытом и рычать. Это нормально. Он не кусается, лишь пытается убедиться, что вы не бездельничаете.
Единственный вариант точно оценить время, затраченное на разработку это начать и завершить разработку.
Но так как в случае с Селектелом декомпозицию осуществляют менеджер с клиентом, неудивительно, почему такие идеи приходят в их головы.
Вам платят не за сроки
…а значит, мы не можем назвать заказчику даже примерные сроки окончания проекта.
Отдельным пунктом идет идея о том, что заказчику необходимо знать сроки. А деньги вам платят тоже за сроки?
С одной стороны, менеджменту хватило яиц продавить изменения, с другой стороны, их не хватило, чтобы объяснить клиенту, что сначала мы выпустим MVP, и если это то, что заказчик хотел, будем заполнять функциональностью, которая для него более приоритетна.
Вместо этого, клиент по-классике выломал руки менеджеру и заставил дать сроки.
Ваша задача как менеджера заключается только в том, чтобы донести эту простую мысль до заказчика. Если вы не смогли этого сделать, значит вы проф. непригодны.
Потеря времени и денег
Так как клиенту «дали сроки», то появляется время, которое после прототипирования можно бесцельно потратить. Например, на документацию прототипа или кодревью.
Ревьюить и документировать будут, естественно, весь код, в том числе тот, который будет переделан или выброшен. Вся эта затея со сроками и плейсхолдерной активностью лишь увеличивает стоимость проекта для заказчика.
Проблема ревью по факту сделанной работы в том, что это ревью не происходит, когда оно наиболее необходимо - во время принятия решений.
Откладывать ревью в конец спринта не только бесполезно, но еще и вредно, бо человек уже принял серию неверных решений и место остается только для критики.
Было бы хорошо, если бы каждый разработчик мог бы проконсультироваться с другим или посидеть над проблемой вместе, подумать. Этому помогает, например, парное программирование.
Но настоящие агиле подходы делают работу над задачей по определению Нукси, более «Стихийной» и «Непредсказуемой».
Четкость ведения задач обеспечивают чек-листы
Чтобы прочно внедрить вредные практики, пришлось делать делать чек-листы. Сам чеклист это отдельный позор для организации. Смотрите на него под спойлером.
Чеклист, без которого можно обойтись, если ты делаешь все правильно
Судя по чек-листу, они документируют еще и эндпоинты в своем API. Тут либо менеджменту swagger’а было недостаточно. Либо у них не было swagger’а, что показывает, что в Selectel помимо плохих менеджерских практик, есть еще и плохие инженерные практики.
Слежка - дело рук отслеживаемого
Следующая проблема, которую мы решали, — это хаос при заведении задачи, их стихийное принятие в работу. Не всегда было понятно, какой задачей на текущий момент занимается конкретный член команды…
В команде всего 10 человек, из них четверо - менеджеры. Все четыре менеджера не смогли уследить за 6 программистами. Если это не роспись в своей проф. непригодности, я не знаю, что это.
Дальше статью разбирать нет смысла, далее следуют логические выводы, закольцованные на себя и длинная тирада о том, что деградацию рабочего процесса и круговую поруку все хотели и все поддержали.
Вы сделали все неправильно
Я люблю правильные подходы, например, TDD.
Пока ты пишешь тесты, получается и дешевле, и качественнее потому, что выходит меньше брака. Делая тесты наперед, ты реже ошибаешься, а исправление ошибок становится быстрее. Тесты так же служат своеобразной документацией к коду и составляют фундамент для крупных безопасных изменений.
По моему мнению, Agile подход это TDD для менеджмента. Мы получаем быструю обратную связь, быстро вносим правки и не тратим время на реализацию нашего недопонимания.
Быстрее цикл обратной связи, меньше «бракованного» общения с клиентами, меньше работы менеджерам и разработчикам. Меньше издержки на нашу компанию и нашего клиента.
В селектеле, возможно, практиковали агиле, на это намекает словосочетание «Двухнедельные спринты», но Нукси сделала все, чтобы угробить остатки.
В конечном итоге они всем отделом приползли к ухудшенной версия ватерфолла, где задачи спускает не архитектор, знакомый с кампанией и коллективом, а заказчик с менеджером.
Фейл селектела не только в менеджменте
Идиотический чек-лист продавить было почти невозможно, если бы разработчики изначально обеспокоились бы CI/CD и acceptance testing’ом. Если вы уже занимаетесь TDD, настроить пайплайн это дело двух минут, а менеджера отпугнет. Скорее всего, они не занимались ни тем ни другим.
Более того, разработчики поделились на разработчиков бизнес-логики и разработчиков базы данных.
Если даже с помощью гугла, вы не можете написать хранимую процедуру, а вместо этого, целую неделю отдельный человек пишет её вам, возможно, разработка это не для вас, и ваше место за плитой во «Вкусно и точка».
Если все, что вы умеете, это писать хранимые процедуры и добавлять таблицу в базу, то у меня тоже плохая новость. Ваша профессия - сисадмин, в лучшем случае. В связи с этим, возможно, вам стоит пересмотреть свои зарплатные ожидания.
Придя в нормальный коллектив, сложно себе представить, чем бы все эти бездельники занимались.
Задача как менеджера, так и программиста, помочь бизнесу заработать больше денег и сократить издержки. Поэтому вы, как разработчик делаете все по-красоте, либо эффективный менеджер увидит слабость и начнет её эксплуатировать.
Выбор стоит так: либо технократия, либо бюрократия.
Дизайн наперед не работает
Практика делать весь дизайн наперед не работает и работать не будет. Ни заказчик, ни менеджер, ни разработчик не понимают что делают и говорят. Это нормально, так всегда было.
Если вы делаете весь дизайн наперед как Нукси это делает, за эти поставленные 2 недели не написана ни одна строчка кода. Это не только трата времени на дизайн, который не взлетит, но дизайн, который априори не исходит из реалий стека и языка.
Правда декомпозиции в том, что на самом деле, разработчики стучатся головой об проблему до тех пор, пока эта декомпозиция путем проб и ошибок, не появится сама.
Но в итоге мы имеем время, потраченное на менеджера, чтобы он мог сказать, что чем-то занимался.
Схитрить не получится
Все, у кого есть мозг и все, кто умеют свой мозг думать, понимают, что чем больше у тебя работы, тем больше на тебе нагрузка.
Если от перестановки слагаемых у вас меняется сумма, значит в уравнении где-то ошибка.
В селектеле время, которое ранее уходило на коммуникацию, теперь уходит на печатание кода, который все равно придется переделывать.
В одной компании (называть не буду), успех менеджмента определяется количеством информации, которой они поделились с остальными.
Например, если менеджер филиала находит оптимизацию, и эта оптимизация заходит остальными филиалам, значит, менеджер действительно занимается менеджментом.
Он сокращает излишние расходы, добивается большего, используя меньшее.
Если вы добавляете бюрократию, значит вы занимаетесь не менеджментом. Если вы меняете агиле на ватерфол, значит вам не место в профессии.
Послесловие
Разбирать такой материал крайне сложно, тут негде ставить пробы. Каждое неверное решение тянет за собой хвост из мгновенных и отложенных последствий.
Оригинальная статья написана в хронологическом порядке, по мере принятия решений. Но логика этих решений не следует из возникающих проблем или из стремления достижения результатов.
Реальная ситуация, скорее всего, представляет серию арбитрарных решений в сугубо личных целях, а проблемы, скорее всего, были высосаны из пальца или додуманы, чтобы продать реформы вышестоящему начальству.
Подозреваю, что мы имели дело с частным случаем Job Security Driven Development’ом, только со стороны менеджмента. Менеджер поняла, что в коллективе, где разработчики общаются с заказчиками напрямую, она выполняла роль не большую, чем девушка на ресепшне.
Если посмотреть на оригинальный материал с этой точки зрения, то все эти изменения начинают нести гораздо больший смысл.
Как же хорошо, Нукси, что я работаю не с вами.
Комментарии (46)
globeit
15.06.2023 10:13-14Очень странная статья, с высосанными из пальца тезисами, которые автор тут же бросается аргументировать. Крайне похоже, что кто-то заказал опубликовать негатив про Селектел, причем с самой компанией, судя по всему, этот автор вообще не знаком.
P.S. Посмотрел, пару дней назад была опубликована еще одна статья с негативом против Селектела, причем сделано топорно - типа выбрали несколько компаний, для всех прочих отметили малюсенькие недостаточки, по Селектелу прошлись огнем и мечом. Неделя проплаченного негатива против этой компании объявлена? ) Очень все шито белыми нитками, ребят. Не надо так.
nneeoo Автор
15.06.2023 10:13+51Проплаченная компания...
Высосанная из пальца...Прошу прощения, но вы звучите как сотрудник селектела.
Под этим постом нет и двух тысяч просмотров, а вы уже накрутили 14 плюсов под свой комментарий.
Если вы действительно сотрудник, должен вам сообщить, в своих накрутках вы не знаете берегов.globeit
15.06.2023 10:13-16Ну и снова то же самое - высосанный из пальца тезис и тут же обвинение. Насчет "не знаете берегов" - тут уже какой-то жаргон пошел, простите, но я в таком стиле не общаюсь.
Эдак мы дойдем с вашей стороны до: "Ты из какого района?" :)
Насчет плюсов - возможно, просто статья реально странно выглядит и читатели плюсуют адекватный комментарий? Но это лишь мое предполжоение. На этом дискуссию считаю оконченной, я отвечать больше не буду.
vvzvlad
15.06.2023 10:13+19Как интересно-то: сначала рейтинг комментария был +14, а теперь уже ноль, и судя по всему, уверенно движется к отрицательному. Хотя в дискуссии не то, чтобы объявились новые факты. Мне все больше нравится версия о накрученных в начале плюсах, которые затем догнало сообщество.
DMGarikk
15.06.2023 10:13+48кто-то заказал опубликовать негатив про Селектел,
… еще одна статья с негативом против Селектела
сделано топорно — типа выбрали несколько компаний, для всех прочих отметили малюсенькие недостаточки
Неделя проплаченного негатива против этой компании объявлена? ) Очень все шито белыми нитками, ребят.ну вы реально же сотрудник Селектела?
вы же отвечаете в стиле "ответа бизнеса" в комментариях к продуктам маркетплейсов в стиле "пошли вон злые конкуренты!!"даже если это реально проплаченный антипиар, очень странно что именно вас (если вы мимокрокодил) это прям зацепило.
blik13
15.06.2023 10:13+35По селектелу прошлись огнем и мечом с данными тестов. Любой заинтересованный может повторить эти тесты и удостовериться или опровергнуть их.
mvv-rus
15.06.2023 10:13+21Очень странная статья,
...однако, весьма характерная именно для этого автора своей провокационностью: посмотрите его публикации (и среди них есть одна явно непроплаченная - про слитые сорсы). Кстати, я бы на месте НЛО тут бы перед каментами плашку бы поставил, ту, которая про "противоречивые чувства".
Крайне похоже, что кто-то заказал опубликовать негатив про Селектел
Проверьте свою гипотезу: например, посмотрите, нет ли подобных статей на других аналогичных ресурсах, типа vc.ru. И, пожалуйста, сообщите результаты проверки (мне будет интересно - vc.ru я, например, не читаю, потому что он - не для технарей) .
Учтите, что есть и альтернативная гипотеза появления этой статьи: накрутки плюсов в корпоративных блогах реально достали (меня, например - тоже, и, гляжу в каменты - не только меня). Только вот большинству тех, кому накрутки не нравятся, писать статью по такому поводу либо лень, либо некогда. Но, вот, в результате, нашелся человек, который решил-таки выразить свое отношение к Селектелу: нашел и расккритиковал статью, где Селектел явно подставился.
venanen
15.06.2023 10:13+37Отличная статья. Во-первых, я очень рад, что кто-то снова поднял вопрос голосов в корпоративном блоге. Я одно время даже сидел и ковырял статистику, благо хабр отдает все посты по JSON API со всеми полями. Там много интересного, но статью таки писать стало лень. Айтишный ресурс не способен бороться с накруткой, хотя достаточно банально посмотреть на распределение просмотров лайков во времени после выхода (а у некоторых корпоративных блогов +10 сразу после публикации, чтобы на главную попасть), и на коэффициент лайков к просмотрам. Собственно, достаточно зайти в профильные хабы, чтобы посмотреть, какие крутые статьи там висят с низким рейтингом, зато на главной 10 видов лечения зубов и почему аборигены съели Кука.
А во-вторых, я уже продолжительное время вижу нарастание менеджерского безумия. Вероятно, это связано с тем, что разработчиком стать все-таки сложнее, нужно иметь склад ума инженерный, способности и теорию, с менеджерскими позициями все проще. И начинается какой-то цирк с конями, лишние телодвижения, 10 митапов в неделю на разные темы, потому что так надо, стендапы, игры в ДНД в обязательном порядке, корпоративные обливания водой в день Нептуна, танцы и пляски и другие проявления современных методологий управления персоналом. И все бы ничего, ладно, но все это на фоне горящих дедлайнов. И все больше менеджеров я вижу, которые не в состоянии ТЗ составить, оценить время, договориться о чем-то с заказчиком, зато знают 1000 и 1 способ отвлечь разработчика от работы.
Keeper9
15.06.2023 10:13+4ДНД -- это ещё неплохо, главное, чтобы не БДСМ.
laatoo
15.06.2023 10:13+9а можно лучше БДСМ?
lorc
15.06.2023 10:13+20БДСМ хотя бы заявляет о трех главных принципах: безопасности, добровольности, разумности. Чего не скажешь о корпоративной разработке...
datacompboy
15.06.2023 10:13+8Предлагаете добавить в процессы стоп-слово?
lorc
15.06.2023 10:13+5Ага. И aftercare после двухчасовых совещаний.
datacompboy
15.06.2023 10:13+4Отдельный cuddle-ing room на выходе из meeting dungeon?... Звучит разумно, добровольно, главное чтоб SFW.
sshmakov
15.06.2023 10:13Каждый раз поражаюсь широте познаний айтишников. Даже, казалось бы, в сферах, далеких от профессии.
datacompboy
15.06.2023 10:13Мне рассказывали как выглядел отдел девушек-"божьих одуванчиков" в Яндексе, занимающихся классификацией NSFW картинок и поисковых запросов для детской фильтрации.
Я лично наблюдал примерно такую же картину в виде милейших созданий, которые извиняющимся тоном говорили: "у нас нету в лаборатории молотков... вот, разводной ключик, мы им мышек подготавливаем" (ключ весом килограмма в 2 весь бурый от запекшейся крови -- они реально мышек к исследованиям после экспериметов им "подготавливают")...
Короче, не надо встречать по профессии :)
barloc
15.06.2023 10:13+8Непонятно, что сказать то хотели? Что у них все плохо? И зачем приплетать свой опыт разработки к отчетности?
Все, у кого есть мозг и все, кто умеют свой мозг думать, понимают, что чем больше у тебя работы, тем больше на тебе нагрузка.
Не совсем так. Работа состоит из много чего: проектирование, реализация, тестирование, приемка. А когда это все делает один человек, все становится намного сложнее из-за когнитивной нагрузки.
Чтобы хоть как-то ее снизить и решили выстроить конвеер, по крайней мере отделив техничку от бизнеса. Причем это стандартный прием в такого рода командах по мере их роста.
Если вы делаете весь дизайн наперед как Нукси это делает, за эти поставленные 2 недели не написана ни одна строчка кода. Это не только трата времени на дизайн, который не взлетит, но дизайн, который априори не исходит из реалий стека и языка.
Ох как поспорил бы с вами Самый лучший программист Deadline ДеМарко...
Andypuh
15.06.2023 10:13+9Вообще странно, судить о процессах работы компании на примере описания процесса внутренней команды, которая занимается созданием дашбордов для внутренних нужд с множеством заказчиков, у которых могут быть разные требования к одним дашбордам, данным и т.д.) Скажем так, это мягко говоря не классическая разработка, а уж тем более не продуктовая разработка продуктовой команды.
Но, тем не менее, описанные изменения в этой команде улучшили их жизнь, а возможно и жизнь их заказчиков, соответственно цель изменений была достигнута. Процессы подстраиваются под контекст, серебряной пули тут нет.
Nuxi
15.06.2023 10:13+4Привет! Очень здорово, что мой текст так вас заинтересовал. Стиль письма животрепещущий)
Мы делали процесс, опираясь на возникшие трудности и собственный опыт. → Изменения нам помогли, ни один разработчик или заказчик при этом не пострадал ???? Понимаю, что в контексте вашего опыта выводы могут быть иные. Интересно, где и кем вы работаете, что появилась такая нелюбовь к менеджерам?)
nneeoo Автор
15.06.2023 10:13+10Я, в свою очередь, тоже рад, что мой текст заинтересовал вас. Надеюсь, моя статья поможет вам сформировать альтернативный взгляд на вашу работу.
vvzvlad
15.06.2023 10:13+7ни один разработчик или заказчик при этом не пострадал ????
А расскажите, как вы это установили?
lodz
15.06.2023 10:13+3Отвечу за автора, поскольку она не очень хочет участвовать в этом диалоге. В команде всего 10 человек, спросить об удовлетворенности процессами несложно. А в Selectel одна из ценностей — открытый фидбэк и прозрачность коммуникаций.
Разработчикам из команды BI-аналитиков текст уважаемого nneeoo не понравился) К слову, ребята поддерживают нашего автора и говорят, что с изменениями процессы стали намного лучше. Цитировать здесь не буду, поскольку это частная переписка.
datacompboy
15.06.2023 10:13+4У автора статьи здесь явно бомбит и очень сильно, да. Формат изложения мыслей не из лучших, да. Однако же вы при этом не услышали главной мысли статьи -- согласно внешнего осмотра, имеющиеся процессы настроены не для достижения глобального максимума, а исключительно методом бега от локальных минимумов пришли к далеко не оптимальному монстру. И этого даже и не заметили.
Нужен полноценный рефакторинг, а не поза "у меня всё работает"
TiTreivan
15.06.2023 10:13имеющиеся процессы настроены не для достижения глобального максимума, а исключительно методом бега от локальных минимумов пришли к далеко не оптимальному монструЭто вы так неочевидно обыграли проблему "жадных" алгоритмов? Или я неправильно интерпретировал?
datacompboy
15.06.2023 10:13+1В смысле, неочевидно?
TiTreivan
15.06.2023 10:13Неочевидно в моем понимании, это когда рядовой выпускник школы - не поймет. Но вообще да, нужно было уточнить, неочевидно для меня, я не смог однозначно понять, что имелось ввиду. Поэтому прошу все же ответить на вопрос, объяснить что имелось ввиду в более простых формулировках
datacompboy
15.06.2023 10:13+2Взяли процесс организации труда и неумело его вкорячили. Резонно огребли проблем и сложностей. Начали проблемы решать по очереди и по одной. На выходе получили процесс-химеру, который не должен существовать.
Как участники процесса преобразования - не заметили, что родили монстра.
Да, жадные алгоритмы приводят к такому. "жадные" в данном случае могут иметь десяток трактовок но это уже не специально.
sshmakov
15.06.2023 10:13+6Не хочу разбираться в бизнесе Selectel, но хочу заметить, что Agile в варианте Scrum слабо применим там, где нужен конвейер и сроки. Этим объясняется частая трансформация Скрама в водопад. А мимикрия получившегося водопада под Agile объясняется желанием менеджеров "быть в тренде".
santa324
15.06.2023 10:13+2С одной стороны вся критика в статье правильная, с другой стороны похоже автор сам сторонник бюрократии, тдд - та же бюрократия. Стоит разработке стать чуть более алгоритмической или МЛ, и с тдд будут те же проблемы что и с бюрократией из статьи.
sickfar
15.06.2023 10:13+7Я не очень понимаю, каким именно образом аналитики из оригинальной статьи превратились в менеджеров. Аналитики - такие же работники, как и программисты, находятся примерно на том же уровне пищевой пирамиды. Не вижу ничего крамольного в выделении аналитиков в отдельную подкоманду при условии плотного взаимодействия с разработчиками. Лично я читаю слово «методолог» как «эксперт», эксперт в том, что программист не знает. Когда вы пишете бухгалтерский софт, вам нужен эксперт области, методолог, аналитик - как угодно. Иначе программисту придется изучать бухгалтерию. Если это отчеты - нужен методолог, который знает как это отчеты читаются в первую очередь, а не как строятся.
Также не очень понимаю, почему у автора бомбит от дачи сроков заказчику. Подписание любого контракта подразумевает подписание его на определенный срок, в течение которого работа должна быть выполнена. Нормальный адекватный процесс при этом подразумевает возможность их изменения, но в любом случае все начинается со сбора требований, их грануляризации и оценки.
Отдельным пунктом идет идея о том, что заказчику необходимо знать сроки. А деньги вам платят тоже за сроки?
В любом случае заказчику необходимо понимать, когда он это получит, чтобы подстроить свои процессы. Обеспечить железо, подготовить работников - это все не появляется ниоткуда, а требует расчета бюджета, амортизации, подготовки. Не только исполнитель делает работу, но и заказчик со своей стороны тоже.
Ну и главный мой вопрос - а как надо? Я, например, так и не понял.
lodz
15.06.2023 10:13Уважаемые nneeoo, спасибо, что уделили столько внимания тексту в нашем блоге. Интересно, что вы расчехлили свой токсикомет именно на наш блог — с нетерпением жду ваших следующих текстов. Ведь про оптимизацию процессов и работу в команде корпоративные блоги на Хабре пишут довольно часто. Уверена, с учетом вашего стиля «возьму абзац и напишу свое фи» у вас получится не менее вдохновляющие публикации, направленные на хайп :)
Что бы вы ни писали, изменения, которые ребята реализовали в команде, для них сработали. Возможно, они сработают для кого-то еще. Заметьте, что в тексте наш автор не писала, что это догма для всех.
Надеюсь, у вас есть работа, где вы используете ваши глубокие знания о менеджменте в разработке. Возможно, стоит встать с места диванного критика и рассказать, как правильно все устроено именно у вас в команде. Мы обязательно возьмем на заметку. Всего хорошего)
nneeoo Автор
15.06.2023 10:13+4Спасибо что уделили время моей токсичной проплаченной статье!
Надеюсь, деньги моего заказчика смогут улучшить положение дел в вашей компании!
NoGotnu
15.06.2023 10:13+4Если даже с помощью гугла, вы не можете написать хранимую процедуру, а вместо этого, целую неделю отдельный человек пишет её вам, возможно, разработка это не для вас, и ваше место за плитой во «Вкусно и точка».
Если все, что вы умеете, это писать хранимые процедуры и добавлять таблицу в базу, то у меня тоже плохая новость. Ваша профессия - сисадмин, в лучшем случае. В связи с этим, возможно, вам стоит пересмотреть свои зарплатные ожидания.
С самого начала статья выглядела как попытка выпендриться в незнакомой области, в которой похоже автор вообще не разбирается, а после этого абзаца вообще всё стало ясно. Видимо в представлении автора программисты баз данных только пишут хранимую процедуру и добавляют табличку в базу. Видел я поделки таких "спецов".
Надеюсь операцию на сердце вам тоже сделает хирург-проктолог, с Гуглом наперевес. Иначе ему место во вкусно и точка.
laatoo
15.06.2023 10:13+2программисты баз данных
кто такие программисты баз данных? вы про DBA?
DMGarikk
15.06.2023 10:13+5кто такие программисты баз данных?
вполне себе существуют программисты на PL/SQL
И крупные корпоративные продукты где большая часть бизнеслогики находится в хранимых процедурах БД
p.s. не буду судить хорошо это или плохо, это факт, в финсекторе такое видел
vadim_bv
15.06.2023 10:13Один из моих любимых вопросов на собеседовании: чем можно заменить триггер на табличку в БД?
Можем порассуждать вне контекста хранимых процедур?datacompboy
15.06.2023 10:13Зависит от кучи переменных в имеющихся требованиях.
Например, может быть решено через:
Код в ORM слое
Можно повесить Server-side сниффер или прокси
Если не срочно -- то от Diff между бакапами до фонового сканнера
Ну и никто не мешает просто всегда в транзакции делать все вещи вручную. Иногда это еще и лучшее решение...
Areso
15.06.2023 10:13Зависит от СУБД. Например c MySQL можно использовать ProxySQL, а там используем правила =)
А вообще тут просто такой вопрос - уверены ли мы, что все наши write коннекты будут идти через ORM / ProxySQL / любое третье решение?
У меня сейчас ситуация, когда к 1 БД подключаются легаси приложения и новые приложения, большинство через ProxySQL, но есть и прямые коннекты, в БД творится некий ужас.
laatoo
Крушение менеджерских фантазий суровой правдой разработки в реальном мире :)
Фантазия: "декомпозируем, проектируем, документируем, согласовываем с заказчиком четкий срок, разрабатываем, укладываемся в спеку и срок, все счастливы, готово".
Реальность: в начале получаем векторное понимание проекта, по ходу дела вместе с заказчиком и командой разбираемся в деталях, переписывая и переделывая из-за недопонимания заказчиком/командой реально происходящих процессов, и процессов которые должны происходить (нередко таким образом чиним бизнес процессы заказчика), мискоммуникации, приходим к MVP, релизим, уточняем требования, получив новые знания о проекте и требованиях в ходе "проверки боем", переписываем заново с учетом новых требований, релизим, саппортим. На каждом этапе боремся с мискоммуникацией со всей силы.
Статья пропитана реальным опытом и пониманием процессов "изнутри", тем и ценна.
Спасибо.
nneeoo Автор
Именно так, рад что кто-то, кроме меня знает, что такое агиле.
Andypuh
А что такое "агиле"? и как манифест можно сравнивать с конкретной методологией?)