С Вашего позволения, пожонглирую немного понятиями. К сожалению, сам лично наблюдаю, как мелеет и изничтожается искусство токсичности в сфере управления. Само понятие токсичности поменяло свое значение. Раньше, когда слово "токсичный" относилось исключительно применительно к веществам, употреблялось слово "м*дак".
Примерами м*дизма можно считать такие действия:
Подставить, подсидеть коллегу
Свалить свою работу на другого
Публично унизить коллегу или подчиненного (помните байку: заставить новичка разобрать станок или движок и подбросить пару лишних болтов в процессе)
"Подколоть" или заставить человека чувствовать обиду, злость, стыд не имея для этого объективных оснований
И если первые пункты, очевидно направлены на личную выгоду - вторые служили инструментом выстраивания иерархии. Это буквально была интеллектуальная дуэль, оружием в которой служили:
Компетенции и профессионализм (наш отдел 3 релиза уже сделал, а ваш 0 - лохи)
Находчивость
Отсутствие страха перед социальными взаимодействиями, демонстрация принятия риска
За счет этих взаимодействий выстраивалась истинная иерархия.
Например голос сильного специалиста мог цениться выше его руководителей, если он отбил все профессиональные нападки, включился в профессиональное соперничество и показал хорошие результаты (решил сложную задачу, показал хорошую результативность), разгадал все подколы, или остроумно ответил на до*бку, продемонстрировав тем самым свой уровень интеллекта, "социальную" подготовку и принятие неформальных правил. Что называется, показал зубы. Как минимум - к такому не лезли, т.к. он может ответить.
Сейчас же, особенно в среде менеджеров и всякого рода ненастоящих руководителей, я наблюдаю буквально 1 единственный прием токсичности: Вместо утверждения задать вопрос, например: "Где детонатор?", вместо "тут нужен детонатор". Вместо вопроса, выдать утверждение, например: "Ну это конечно сейчас на неделю растянется", вместо "сколько это займет времени". Ну может еще заставить объяснять, почему сложная задача - сложная. Но это редко, потому что быстро станет очевидно, кто здесь тупой.
Но самое печальное, что смысл всей этой "токсичности" не в выстраивании иерархии, что определенно необходимо нам, как социальным существам. Не разбор ситуации, не обучение сотрудника. Не улучшение чего бы то ни было.
А просто - компенсация своих внутренних комплексов. Токсичность, и та измельчала.
Причиной этого я вижу какое-то невероятное падение менеджерских и управленческих компетенций. Руководители разработки не умеют писать код. Всякие проджекты не знают ничего, кроме скрама, да и тот еле-еле. Аналитики не умеют писать ТЗ. ПрОдукты ничего не знают про кастдев... Сегодняшняя токсичность - это, скорее, некомпетентность. Я считаю важным говорить об этом.
Теперь, что касается "жесткости". Термин не определен, однако, из текста кажется, что Вы объединяете жесткость и токсичность, что я считаю неверным. Под жесткостью я понимаю последовательное требование следовать определенным, редко изменяемым, правилам и обозначаемым договоренностям. При том, в 2 стороны. т.е. руководитель от себя требует того же. Но, даже безотносительно моего понимания, применительно к токсичности:
Требовать результаты - не токсично. Требовать результаты, противоположные тому, что требовалось вчера - токсично. Требовать результаты от людей другого профиля (например документацию от разработчиков или готовую систему от аналитика) - токсично.
Говорить правду - не токсично. Пытаться возвыситься за счет работника, используя то, что у тебя, как у руководителя, немного больше информации, чем у него - токсично. Унижать кого-то локальным незнанием - токсично.
Помогать расти - не токсично. Кичиться своим превосходством в какой-нибудь мелочи - токсично. Подчеркивать (особенно публично) локальные пробелы в знаниях других - токсично.
В итоге, я хотел бы подвести некоторые выводы под своими размышлениями.
Если руководитель не смог выстроить рабочую атмосферу внутри коллектива
Если руководитель не смог найти общий язык с подчиненными
Если его работникам плохо и некомфортно, они чувствуют обиду
Если работникам постоянно приходится оправдываться и защищаться
Дело тут вот в чем. Два важнейших понятия для канбана: потоки и лимиты. Канбан, как Вы правильно заметили, изначально изобретен именно для конвейерных задач. Т.е. вы "штампуете" на производстве какую-нибудь свистульку - у нее есть этапы, типа (фантазирую): грубая заготовка, точная заготовка, покраска, лакировка, забивание гвоздика - это и будут этапы канбана. Процесс строго определен, спроектирован и посчитан. Тут нет места "переключению" на задачи, так же как и сроков в it-шном понятии. Допустим, 10 минут на свистульку - 6 свистулек в час. Канбан позволяет наглядно видеть следующие ситуации: 1. Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики. 2. Вы хотите увеличить производительность до 7 свистулек в час, для этого смотрите на доску и видите самые загруженные участки - это будут первые претенденты на оптимизацию, а не загруженные, наоборот, можно не трогать.
Проблема же в том, что разработкой новых продуктов в новых отраслях пытаются управлять как 200-летней фабрикой. Такие вот у нас компетенции менеджеров. И соответствующие результаты.
Что-ж, прежде всего хочу сказать, что я разделяю Вашу боль и негодование по поводу скрама. Мое отношение к нему подробнее раскрывается в моих предыдущих комментариях.
Лет 12 назад, когда скрам начал бодро шагать по умам, ходило такое утверждение: "Все, что не по скрам-гайду это не скрам". Теперь же, спустя десятилетие, доказавшее ущербность этого подхода, утверждение сменилось на: "пук-среньк, скрам это набор рекомендаций для профессионалов". Должен сказать, что реально "настоящего" скрама я не встречал ни разу в жизни. Так же и то, что Вы описываете - это, скорее, "краткосрочное планирование", а не скрамный скрам.
Разница в следующем: Во первых, утверждение, что "команда обязана выполнить все запланированные задачи", противоречит положениям скрама. Вот такая неожиданность! В большинстве команд, с которыми я взаимодействовал, тоже, почему-то, воспринимали конец спринта как дедлайн. Тут возникает много вопросов компетенциям менеджеров и скрам-мастеров... Тем не менее, идея скрама(тоже не работающая) как раз в том, что мы не можем ничего заранее спланировать и оценить, но можем начать делать, собрать статистику за пол года, и предположить что в ближайший спринт мы сможем сделать примерно столько же, сколько в предыдущие. Во вторых, задачи следующего спринта, конечно, не стоят в ожидании. Допускается взять в текущий спринт новую задачу, если: а) цели спринта достигнуты б) есть задача, которая по оценке влезет в оставшиеся сторипоинты
Так же, хотел бы заметить темную сторону Kanban-а, которую обычно прячут за формулировками типа "перераспределить ресурсы" или "оптимизировать процесс". Например, если в разделе «Тестирование» накопилось слишком много задач, это может означать, что можно уволить парочку программистов, парочку аналитиков и провести сокращения далее по цепочке - тогда, в теории, выход продукции окажется прежним (сколько может переварить тестировщик), а затраты сократятся. На практике, конечно, надо учитывать пики загрузки разработки, настроения в коллективе, общий уровень комфорта и чувство безопасности работников, и много чего еще. Но простые методы приманивают "простых" людей - в этом есть некоторая опасность.
Изначально я написал едки и токсичный комментарий, дескать покажи свою супер эффективную корпорацию, прежде чем рассказывать нам тут про неэффективность. Было эмоционально. Все стёр. Причиной тому - невероятное засилие вездесущих высокомерных умников, считающих себя профессионалами, просто потому что они хотят быть профессионалами. Хотя гонор, обычно сопровождающий юность, и некоторый юношеский максимализм - это скорее хорошо, но в меру! 20-ти летние наставники наставников, 22-летние сеньеры-разработчики, и прочие фаундеры бирюзовых компаний, не прочитавшие ни одной книжки - смешно. До тошноты смешно.
На днях приходил парень, 27 лет, на собеседование. Позиция мидл. Спрашиваю: "Назови 7 функций из языка, какие вспомнишь". Задаю этот вопрос, чтобы мозг настроился на код, чисто для разминки. Ни одной не назвал. Сюр!
Отчасти, конечно, это мы, старые пердуны, допустили буйный цвет этой инстаграмной чумы, "фэйк ит антил мэйк ит", и прочей чуши. Но лишь отчасти.
Знайте чем отличается профи, от не профи? Профи может сам отличить хорошую книгу от плохой, полезную статью от пустой, а сэндвич от клизмы (если вы понимаете о чем я). Без всяких ссылочек, кратких содержаний и подсказок людей из интернета. Прийти к этому можно лишь одним путем - изучить в достаточном количестве и того и другого.
Вот история из моей жизни. Год примерно 2020. Сутра я немного проспал, знаете как бывает, выключил будильник на телефоне и решил, что встану через 5 минут - была довольно промозглая погода и вылезать из под теплого одеялка совершенно не хотелось. Тем более не хотелось идти на работу.
Но, 25-го надо платить за квартиру, так что даже сквозь дрёму пробивались мысли, будто ничего хорошего меня не ждет, и надо шевелиться изо всех сил, пока хоть что-то у меня шевелится. Мысль "кажется я проспал" разбудила меня примерно через 15 минут после будильника - не критично, но учитывая, что мои утренние ритуалы распланированы буквально по минутам, утро стало наполнено дискомфортом.
Чтобы нивелировать опоздание, а так же учитывая совершенно мерзкую погоду, не дождливую, а такую прозябло-холодную, сопровождающуюся, обычно, ветром от которого не спасает любая одежа, я решил заказать такси до офиса.
Мне досталась типичная машина уровня "эконом", с водилой - седым полноватым русским мужиком, лет 50, слегка напоминающего миядзакавского Kashira, задумчивого и молчаливого, впрочем как и я. Задумчив он был от того, что внимательно слушал радиопередачу - бесконечное болтание на всевозможные темы на какой-то болтологической (совершенно без музыки) волне (я, конечно, предпочитаю в машине послушать музыку: классику (кстати, недавно, так же в таки, услышал радио Орфей - рекомендую), лофи или какую-нибудь рок-древность).
Не смотря на свои предпочтения, именно в таких случаях уровня "такси", где я точно на долго не задержусь, я предпочитаю не приводить окружение в комфортное мне состояние, от части из нежелания лишний раз коммуницировать, от части, потому что надеюсь открыть для себя что-то новое среди бесконечной болтовни, арабских мотивов, и, не отягощенных изобилием нот, современных музыкальных композиций.
Пламя ковида в то время во всю разгоралось по миру, и эта тема, без сомнения, интересовала всех, в том числе меня и ведущих звучащего утомительного радиошоу. Накануне этого не самого приятного дня в Москве проходил какой-то толи форму, толи конференция, на которой выступал Собянин. У него спросили - будут ли вводиться в Москве ограничения, аналогичные другим городам. Я запомнил его ответ слово в слово, поэтому привожу его, как цитату: "Никаких ограничений в Москве вводиться не будет". На следующий день в Москве ввели самые жесткие ограничения, связанные с ковидом.
Словоформы соседних слов иногда могут развеять двусмысленность
UPD: Я тут со второго раза понял, о чем Вы. Вероятно дело в моей дислексии, эмоциональном напряжении в момент написания комментария, а так в же чрезмерном доверии встроенной проверке орфографии. Ответ на вопрос: похоже выбирает рандом.
Эта статья вызвала у меня очень сильный эмоциональный отклик, буквально "Вьетнамские флешбекти" со времен, когда я только начинал свою карьеру разработчика. Это было 15 лет назад, и мне больно от того, что за это время мы пришли к тому же самому. Извиняюсь за тон - эти темы важны для меня на личном уровне; в конце концов, эмоции - это часть, которая делает нас людьми.
Вот несколько вопросов и моментов, которые я хотел бы обсудить.
В заголовке написано: "Нам не нужны кодеры". Вам - это кому? Тем, кто сам не способен стать ни кодером ни инженером, но зато уже готов требовать это с других, повышателей уровня инженерной культуры, стандартизаторов и прочих "эффективных менеджеров"? Без сомнения, кто-то все таки должен делать реальную работу, а не просто требовать ее с других. Вы пишите "Отвечать за результат, ... быть готовым нести ответственность, не деля её" и тут же перекладываете все на разработчиков, дескать это они должны меняться и брать ответственность, но не вы. В древности, ровно в то время, когда не было, как Вы выражаетесь "узкого разделении труда", было такое слово - лицемерие.
Что касается узкого разделении труда - это не прихоть программистов. Просто сложность и количество информации выросло в разы за 20 лет, и освоить сразу все на хорошем уровне практически невозможно. Это закономерный и, в некотором смысле, правильный процесс. Вслед за сложностью растет и время, требуемое на изучение и подготовку, а значит времени остается меньше на изучение всяких других полезных и интересных тем. Мне грустно от того, что такие очевидные вещи приходится расписывать. Времена "мастеров на все руки" прошли. Вы можете в одиночку сделать кирпич, но не можете построить небоскреб.
Вы пишите: "глубокая специализация начинает тормозить IT-производство" - это просто вранье. Наоборот, процессы распараллеливаются, все ускоряется. История это доказывает: продуктов больше, релизы чаще, готовые решения на любой вкус - вот что Я вижу вокруг. Эта проблема - просто Ваша выдумка чтобы оправдать очередное бессмысленное словоблудие, стандартизацию стандартов, спецификацию спецификаций, стандартизацию спецификаций и прочий эффективный менеджмент.
T-shaped культура и прочая чушь пригодна только для "соевых инженеров", бегающих по конференциям про одно и то же, и бесконечно цитирующих одну и ту же книгу, но с других требующих T-shaped компетенций и разбираться во всем на свете. Попробуйте почитать Таненбаума или Кнута - там 7 томов, а не 400 страничек, как у Эванса. Нужны годы чтобы освоить это в совершенстве. Или это только программисты\инженеры должны прочитать и Кнута и Эванса, а великим "стандартизаторам" можно обойтись чем-то одним?
Выше уже замечали, но я не могу обойти этот вопрос стороной. Что такое "Ответственность", о которой Вы пишете, для наемного программиста? Я понимаю, что такое ответственность для владельца - ты принял плохое решение, ты потерял деньги, принял хорошее - получил. А для наемного работника это как? Будете делиться прибылью пропорционально успеху компании или это просто красивые слова и очередная брехология?
Что касается стандартизации, с одной стороны у вас стандарты стандартизации, а с другой Вы пишете про "Выход за рамки", "Инициативность" и "Развитие". Вам не кажется что одно слегка противоречит другому, а истинное "Значение стандартизации" = 0?
Вы пишите: "давайте уже избавимся от образа разработчика как какой-то «биомашины»", но тут же пытаетесь навязать им(нам\мне) какие-то стандарты работы, как у Вас уживается в голове это противоречие? Я - уже не биомашина, от того, попытка надеть на мою сферу очередные "стандартизации" вызывает у меня (и судя по комментариям - не только у меня) некоторое негодование.
Что касается ChatGPT, когда Вы говорите молодым сотрудникам: "скоро тебя заменит какой-нибудь ChatGPT" - это ложь и манипуляция. С самого начала карьеры я слушаю как меня заменит более сильный прогер или более молодой, или теперь ChatGPT. Только вот, как показывает эта статья, любители заменять программистов не способны даже статью без противоречий написать, не то что ТЗ для человека. А уж требования для GPT должны быть еще более проработанными.
Вы говорите о "Коммуникации", но это работает в обе стороны. Почему только прогер должен "общаться с бизнесом, общаться с коллегами", а не наоборот? Может было бы лучше, если бы и со стороны бизнеса было умение общаться с программистами? Интерфейс известен: Техническое задание. Ах да, без прогера же никто не способен его составить (иначе зачем Вы предлагаете разработчикам заниматься и аналитикой?).
В заключении, пока разработчик, или как вы в унизительном ключе выражаетесь, кодер, не напишет код, все ваши потуги бессмысленны. Идея же заставить программиста и анализ провести, и аналитику и ТЗ себе написать, сделать самому, и потестировать еще - не нова. И не полезна. Вы пишите, что скучаете по тому, как было раньше (раньше было лучше, да?). Это буквально анти-развитие и анти-прогресс. Не надо так.
Я бы хотел обсудить следующие 3 утверждения: 1. Нет никакого "Go-to-Market Framework" - разрозненный набор действий в сфере маркетинга не является фреймворком ни в каком понимании. 2. Нет никакого "Product Development Framework" - есть много разных, хороших и плохих, подходов к продуктовой разработке, часть из которых можно назвать фреймворками, но конкретно в этой статье не имеется ввиду какой-то конкретный из них (если имеется - то какой?), а обобщение используется как частное, в силу непонимания автором контекста и наплевательского отношения к тексту и читателям. 3. Эта статья - прекрасный пример того, как нейросеть может нагенерировать бредятину на любую тему и подтвердить и развить практически любое утверждение, даже бесконечно оторванное от реальности.
Укажите пожалуйста ИНН или хотя бы название этой отдельной компании, а то может сложиться впечатление, что никакой отдельной компании нет. Я бы не хотел, чтобы кто либо заподозрил Вас в обмане.
Вот Вы пишите: "У нас с помощью ТРИЗ была создана отдельная компания", уточните пожалуйста, а как называется эта компания? А то, вот, я захожу на сайт "РЕКОНН", и первым пунктом в меню вижу телефонию, и никакой отдельной компании не вижу.
Нет, не тон. По тону мне всё нравится. К тому же, я люблю списки, а в статье много списков. "Покоробила" меня именно суть. В статье описаны процессы всплывания проблем, а тут Вы говорите о ленивых сотрудниках (а ниже еще говорят про делегирование ответственности) - и это слегка подмена понятий. Ленивый сотрудник может (и скорей всего будет) вообще умалчивать о проблемах, и напротив, до последнего говорить что "все хорошо, прекрасная маркиза", потом будет что-то вроде "почти доделал, завтра будет", и только потом "ой, вскрылись непредвиденные обстоятельства". Против этого есть другие инструменты - подписанные коммиты, фактически закрытые задачи, и прочее. Так же как и очень ответственный и трудолюбивый человек тоже может прийти с проблемой. Обходиться с теми и с другими одинаково, наверное неправильно. Так же как и считать, что все кругом д`артаньяны, и только один руководитель в белом пальто стоит красивый.
К тому же, если честно, я не совсем понимаю, что значит "ходить со своей проблемой ко всем остальным" с Вашей точки зрения. По контексту я вижу будто бы это тоже самое, что перекинуть свою работу на другого. Но. Вот допустим, есть у меня задание, напрограммировать систему скидок, или там, картину нарисовать. И я такой: "Не буду рисовать, пусть Вася рисует" - наверное тут надо обсуждать увольнение, а не подумать и погуглить. Или вот, когда руководитель на подчиненных сваливает принятие решений - это уже не "обезьяна", а делегирование, и "вы не понимаете, это другое"?
В статье представлен несколько однобокий подход. Я бы предложил: 1. Рассматривать (и организовывать) процессы решения проблем и обучения отдельно друг от друга, а не мешать все в кучу (это главное, что меня "коробит"). 2. При разборе проблем учитывать более широкий контекст, в частности: - учитывать не только квалификацию, но и специализацию (если я программист, а Вася из моего примера - художник, всё резко переворачивается); - учитывать добросовестность работника и исторические обстоятельства; - учитывать уровень загруженности работника, его уровень стресса и ментальное состояние; - вместо "указать о пробелах в сфере самостоятельности", вносить решения в должностные инструкции и программы обучения; - дополнить этот список.
Отдельно хочу сказать, что я разделяю Вашу боль и искренне Вам сочувствую. Однако, если рассмотреть абстрактную, не относящуюся к кому бы то ни было ситуацию, при которой должностных инструкций нет или есть только формально, внутреннего обучения нет или есть только фикция, оценки персонала нет или есть только 360 для галочки раз в год, проверки компетенций нет, матрицы компетенций нет, бизнесс-процессы не настроены, зоны ответственности четко не определены - наверное корень проблем в ленивых смекалистых сотрудниках. Это уже моя боль.
Нахожу этот подход чрезвычайно вредным и токсичным. Не лезьте к господину диванному управляющему со своими мелочами, а если не ваша зона ответственности - вообще забейте.
Про уровень проблемы конечно красиво. Только вот пара моментов: 1. Эти "уровни", они как-то определены и зафиксированы? Скорее всего нет. Более того, то, что сегодня не очень важно, завтра может оказаться очень важным. Без конкретных критериев, в лучшем случае - рассуждения в пустоту, а в худшем - попытка управляющего слить вниз свою главную задачу - принятие решений. 2. Вижу в этом одну из манипуляций "менеджера-совы", на которую часто попадался, будучи молодым и зеленым. С одной стороны "разбирайся сам со своими проблемами", а с другой "почему не сказал, если видел проблему" - итог: только моральное угнетение, потеря мотивации и лишний стресс для работника - это буквально потеря денег.
Что касается рекомендаций для "миддл-специалиста": "каждый раз спрашивать о их видении решения" - Вам результат нужен или в учителя поиграть? Если на обратную связь работник часто будет получать ответы уровня "иди сам подумай" или, б-же упаси, уроки и поучения о "пробелах в сфере самостоятельности" - просто больше не будет никакой обратной связи.
Устраивать формализаторство вместо коммуникаций, оставлять работника наедине с озвученными проблемами, забивать на проблемы, которые напрямую тебя не касаются - это буквально управление наоборот. Не рекомендую.
Рекомендую вот что: 1. Выстраивать открытые и доверительные отношения между работником и руководителем. Да, злоупотребления надо пресекать (желательно на этапе найма). Но в остальном, если работник приходит с проблемой, пусть даже в своей зоне ответственности, обычно это не спроста - стоит разобраться, стоит поддержать. Особенно в it сфере, где моральный настрой и уровень стресса очень сильно влияют на производительность. 2. Поощрять развитие коммуникаций как между работником и руководителем, так и между работниками, поощрять погружение не только в свою область ответственности, но и в смежные. Развивать культуру честности, особенно при обсуждении проблем, через открытость и безопасность. 3. Минимизировать моральное давление и унижения, категорически исключить "гуру-наставнический" тон, "прокачивание мышления вопросами" и прочие проявления комплекса неполноценности. Прямое обучение - да, введение регламентов - да, корчить из себя всезнайку и великого мастера кунг-фу, только потому что ты на ступеньку выше - нет. 4. Поощрять взаимопомощь внутри команды, создавать атмосферу взаимной поддержки и "чувства локтя". 5. Создавать безопасную среду, не только с физической, но и ментальной точки зрения. Жестко следовать декларируемым моральным принципам. Особенно это касается руководителей.
Ого! Оказывается, разработчики тоже люди, у которых бывают плохие и хорошие дни, а внутри направлений бывают более узкие компетенции и непереносимый опыт. Вот это да, кто бы мог подумать, вау.
Мне пришлось плотно поработать с Битриксом, к тому же вечер пятницы, и мне есть что сказать! Вот мои не "типичные аргументы о недостатках платформы":
Инфоблоки без сомнения являются "сердцем" Битрикс, на них построено очень много решений, в частности каталог товаров в стандартных компонентах магазина. Чтож, попробуем создать инфоблок, заполяем замечательные поля NAME, CODE, IBLOCK_TYPE_ID и т.д. А потом попробуем получить инфоблок - по названию (NAME) находит, по коду (CODE) находит, а по типу (IBLOCK_TYPE_ID ) - нет. Ну как так? А оказывается, для фильтра по типу нужно использовать ключ TYPE, а не IBLOCK_TYPE_ID. Почему, а главное, зачем?
О, документация, любимица всех битриксойдов! Получение списка элементов инфоблока, чуть ли не основной метод Битрикса - в первом же примере кода ошибка. Описание части методов вообще утрачено, пример.
Придумали D7, несколько лет назад, до сих пор создать элемент инфоблока нельзя. Зато у нас "ко-пилоты" и BI-аналитика в последнем обновлении.
Про обновления, кстати. В статье ошибкой номер 1 указано "создание самописных компонентов". А вот без самописных компонентов на чистом Битрксе, да на том же Аспро - ставишь обновление - пропадают цены у товаров. Купить ничего нельзя, в корзину добавить нельзя, все товары недоступны - это так называемая обратная совместимость. Каждое обновление как пороховая бочка - сперва на тесте, потом на тесте теста, потом тестирование теста... ну вы поняли. В итоге придумали параметр "COMPATIBLE_MODE", везде пойди проставь, при обновлении-то нельзя автоматически это сделать.
Или вот, хочешь например сделать в инфоблоке свойство-привязку к разделу. Например что бы показывать сопуствующие товары для элемента, или комплектующие какие-нибудь - к этому же инфоблоку товаров привязать нельзя через админку. Ну почему? А потому что если ты вдруг это сделаешь, сломается непонятно что непонятно где, т.к. часть стандартных механизмов не умеет работать с отдельными свойствами-разделами, а сразу по всем смотрит. Ладно, делаешь отдельный инфоблок "сопутки" - так в некоторых компонентах нельзя 2 инфоблока выбрать\подключить.
Компанию по email получить нельзя... Email и телефоны в отдельную таблицу засунули, ладно многие-ко-многим, понятно. Но почему в эту же таблицу засунули и Email-ы контактов и лидов, всё в кучу.
Или вот еще, допустим, была у вас на сайте форма, создающая лиды в портале. Простой понятный процесс - форму заполнил, лид создался. Обновляешь портал - файлы из формы не грузятся. А почему? Потому что выпилили загрузку файлов в лидах! Как говорится в статье, "встает вопрос «Кто виноват?» "...
Ух наболело, разошелся я что-то. Вот вам последняя загадка.
Как называется таблица в которой хранится URL сайта (для многосайтовости)? Варианты: 1. b_site 2. b_url 3. b_domain 4. b_lang
С Вашего позволения, пожонглирую немного понятиями.
К сожалению, сам лично наблюдаю, как мелеет и изничтожается искусство токсичности в сфере управления.
Само понятие токсичности поменяло свое значение. Раньше, когда слово "токсичный" относилось исключительно применительно к веществам, употреблялось слово "м*дак".
Примерами м*дизма можно считать такие действия:
Подставить, подсидеть коллегу
Свалить свою работу на другого
Публично унизить коллегу или подчиненного (помните байку: заставить новичка разобрать станок или движок и подбросить пару лишних болтов в процессе)
"Подколоть" или заставить человека чувствовать обиду, злость, стыд не имея для этого объективных оснований
И если первые пункты, очевидно направлены на личную выгоду - вторые служили инструментом выстраивания иерархии. Это буквально была интеллектуальная дуэль, оружием в которой служили:
Компетенции и профессионализм (наш отдел 3 релиза уже сделал, а ваш 0 - лохи)
Находчивость
Отсутствие страха перед социальными взаимодействиями, демонстрация принятия риска
За счет этих взаимодействий выстраивалась истинная иерархия.
Например голос сильного специалиста мог цениться выше его руководителей, если он отбил все профессиональные нападки, включился в профессиональное соперничество и показал хорошие результаты (решил сложную задачу, показал хорошую результативность), разгадал все подколы, или остроумно ответил на до*бку, продемонстрировав тем самым свой уровень интеллекта, "социальную" подготовку и принятие неформальных правил. Что называется, показал зубы. Как минимум - к такому не лезли, т.к. он может ответить.
Сейчас же, особенно в среде менеджеров и всякого рода ненастоящих руководителей, я наблюдаю буквально 1 единственный прием токсичности:
Вместо утверждения задать вопрос, например: "Где детонатор?", вместо "тут нужен детонатор".
Вместо вопроса, выдать утверждение, например: "Ну это конечно сейчас на неделю растянется", вместо "сколько это займет времени".
Ну может еще заставить объяснять, почему сложная задача - сложная. Но это редко, потому что быстро станет очевидно, кто здесь тупой.
Но самое печальное, что смысл всей этой "токсичности" не в выстраивании иерархии, что определенно необходимо нам, как социальным существам. Не разбор ситуации, не обучение сотрудника. Не улучшение чего бы то ни было.
А просто - компенсация своих внутренних комплексов. Токсичность, и та измельчала.
Причиной этого я вижу какое-то невероятное падение менеджерских и управленческих компетенций.
Руководители разработки не умеют писать код. Всякие проджекты не знают ничего, кроме скрама, да и тот еле-еле. Аналитики не умеют писать ТЗ. ПрОдукты ничего не знают про кастдев...
Сегодняшняя токсичность - это, скорее, некомпетентность. Я считаю важным говорить об этом.
Теперь, что касается "жесткости". Термин не определен, однако, из текста кажется, что Вы объединяете жесткость и токсичность, что я считаю неверным.
Под жесткостью я понимаю последовательное требование следовать определенным, редко изменяемым, правилам и обозначаемым договоренностям. При том, в 2 стороны. т.е. руководитель от себя требует того же.
Но, даже безотносительно моего понимания, применительно к токсичности:
Требовать результаты - не токсично. Требовать результаты, противоположные тому, что требовалось вчера - токсично. Требовать результаты от людей другого профиля (например документацию от разработчиков или готовую систему от аналитика) - токсично.
Говорить правду - не токсично. Пытаться возвыситься за счет работника, используя то, что у тебя, как у руководителя, немного больше информации, чем у него - токсично. Унижать кого-то локальным незнанием - токсично.
Помогать расти - не токсично. Кичиться своим превосходством в какой-нибудь мелочи - токсично. Подчеркивать (особенно публично) локальные пробелы в знаниях других - токсично.
В итоге, я хотел бы подвести некоторые выводы под своими размышлениями.
Если руководитель не смог выстроить рабочую атмосферу внутри коллектива
Если руководитель не смог найти общий язык с подчиненными
Если его работникам плохо и некомфортно, они чувствуют обиду
Если работникам постоянно приходится оправдываться и защищаться
Это плохой руководитель.
E-Банк
Похоже геймхаб всё
Дело тут вот в чем.
Два важнейших понятия для канбана: потоки и лимиты.
Канбан, как Вы правильно заметили, изначально изобретен именно для конвейерных задач. Т.е. вы "штампуете" на производстве какую-нибудь свистульку - у нее есть этапы, типа (фантазирую): грубая заготовка, точная заготовка, покраска, лакировка, забивание гвоздика - это и будут этапы канбана. Процесс строго определен, спроектирован и посчитан. Тут нет места "переключению" на задачи, так же как и сроков в it-шном понятии. Допустим, 10 минут на свистульку - 6 свистулек в час.
Канбан позволяет наглядно видеть следующие ситуации:
1. Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики.
2. Вы хотите увеличить производительность до 7 свистулек в час, для этого смотрите на доску и видите самые загруженные участки - это будут первые претенденты на оптимизацию, а не загруженные, наоборот, можно не трогать.
Проблема же в том, что разработкой новых продуктов в новых отраслях пытаются управлять как 200-летней фабрикой. Такие вот у нас компетенции менеджеров. И соответствующие результаты.
Что-ж, прежде всего хочу сказать, что я разделяю Вашу боль и негодование по поводу скрама. Мое отношение к нему подробнее раскрывается в моих предыдущих комментариях.
Лет 12 назад, когда скрам начал бодро шагать по умам, ходило такое утверждение: "Все, что не по скрам-гайду это не скрам". Теперь же, спустя десятилетие, доказавшее ущербность этого подхода, утверждение сменилось на: "пук-среньк, скрам это набор рекомендаций для профессионалов".
Должен сказать, что реально "настоящего" скрама я не встречал ни разу в жизни. Так же и то, что Вы описываете - это, скорее, "краткосрочное планирование", а не с
крамный скрам.Разница в следующем:
Во первых, утверждение, что "команда обязана выполнить все запланированные задачи", противоречит положениям скрама. Вот такая неожиданность! В большинстве команд, с которыми я взаимодействовал, тоже, почему-то, воспринимали конец спринта как дедлайн. Тут возникает много вопросов компетенциям менеджеров и скрам-мастеров...
Тем не менее, идея скрама(тоже не работающая) как раз в том, что мы не можем ничего заранее спланировать и оценить, но можем начать делать, собрать статистику за пол года, и предположить что в ближайший спринт мы сможем сделать примерно столько же, сколько в предыдущие.
Во вторых, задачи следующего спринта, конечно, не стоят в ожидании. Допускается взять в текущий спринт новую задачу, если:
а) цели спринта достигнуты
б) есть задача, которая по оценке влезет в оставшиеся сторипоинты
Так же, хотел бы заметить темную сторону Kanban-а, которую обычно прячут за формулировками типа "перераспределить ресурсы" или "оптимизировать процесс".
Например, если в разделе «Тестирование» накопилось слишком много задач, это может означать, что можно уволить парочку программистов, парочку аналитиков и провести сокращения далее по цепочке - тогда, в теории, выход продукции окажется прежним (сколько может переварить тестировщик), а затраты сократятся. На практике, конечно, надо учитывать пики загрузки разработки, настроения в коллективе, общий уровень комфорта и чувство безопасности работников, и много чего еще. Но простые методы приманивают "простых" людей - в этом есть некоторая опасность.
Изначально я написал едки и токсичный комментарий, дескать покажи свою супер эффективную корпорацию, прежде чем рассказывать нам тут про неэффективность. Было эмоционально. Все стёр. Причиной тому - невероятное засилие вездесущих высокомерных умников, считающих себя профессионалами, просто потому что они хотят быть профессионалами. Хотя гонор, обычно сопровождающий юность, и некоторый юношеский максимализм - это скорее хорошо, но в меру! 20-ти летние наставники наставников, 22-летние сеньеры-разработчики, и прочие фаундеры бирюзовых компаний, не прочитавшие ни одной книжки - смешно. До тошноты смешно.
На днях приходил парень, 27 лет, на собеседование. Позиция мидл. Спрашиваю: "Назови 7 функций из языка, какие вспомнишь". Задаю этот вопрос, чтобы мозг настроился на код, чисто для разминки. Ни одной не назвал. Сюр!
Отчасти, конечно, это мы, старые пердуны, допустили буйный цвет этой инстаграмной чумы, "фэйк ит антил мэйк ит", и прочей чуши. Но лишь отчасти.
Знайте чем отличается профи, от не профи? Профи может сам отличить хорошую книгу от плохой, полезную статью от пустой, а сэндвич от клизмы (если вы понимаете о чем я). Без всяких ссылочек, кратких содержаний и подсказок людей из интернета. Прийти к этому можно лишь одним путем - изучить в достаточном количестве и того и другого.
Элияху М. Голдратт - Цель
Ицхак Адизес - Управление жизненным циклом корпораций
Вот история из моей жизни. Год примерно 2020. Сутра я немного проспал, знаете как бывает, выключил будильник на телефоне и решил, что встану через 5 минут - была довольно промозглая погода и вылезать из под теплого одеялка совершенно не хотелось. Тем более не хотелось идти на работу.
Но, 25-го надо платить за квартиру, так что даже сквозь дрёму пробивались мысли, будто ничего хорошего меня не ждет, и надо шевелиться изо всех сил, пока хоть что-то у меня шевелится. Мысль "кажется я проспал" разбудила меня примерно через 15 минут после будильника - не критично, но учитывая, что мои утренние ритуалы распланированы буквально по минутам, утро стало наполнено дискомфортом.
Чтобы нивелировать опоздание, а так же учитывая совершенно мерзкую погоду, не дождливую, а такую прозябло-холодную, сопровождающуюся, обычно, ветром от которого не спасает любая одежа, я решил заказать такси до офиса.
Мне досталась типичная машина уровня "эконом", с водилой - седым полноватым русским мужиком, лет 50, слегка напоминающего миядзакавского Kashira, задумчивого и молчаливого, впрочем как и я. Задумчив он был от того, что внимательно слушал радиопередачу - бесконечное болтание на всевозможные темы на какой-то болтологической (совершенно без музыки) волне (я, конечно, предпочитаю в машине послушать музыку: классику (кстати, недавно, так же в таки, услышал радио Орфей - рекомендую), лофи или какую-нибудь рок-древность).
Не смотря на свои предпочтения, именно в таких случаях уровня "такси", где я точно на долго не задержусь, я предпочитаю не приводить окружение в комфортное мне состояние, от части из нежелания лишний раз коммуницировать, от части, потому что надеюсь открыть для себя что-то новое среди бесконечной болтовни, арабских мотивов, и, не отягощенных изобилием нот, современных музыкальных композиций.
Пламя ковида в то время во всю разгоралось по миру, и эта тема, без сомнения, интересовала всех, в том числе меня и ведущих звучащего утомительного радиошоу. Накануне этого не самого приятного дня в Москве проходил какой-то толи форму, толи конференция, на которой выступал Собянин. У него спросили - будут ли вводиться в Москве ограничения, аналогичные другим городам. Я запомнил его ответ слово в слово, поэтому привожу его, как цитату: "Никаких ограничений в Москве вводиться не будет".
На следующий день в Москве ввели самые жесткие ограничения, связанные с ковидом.
Везде только первый вариант
По контексту можно предположить значение слова
Словоформы соседних слов иногда могут развеять двусмысленность
UPD: Я тут со второго раза понял, о чем Вы. Вероятно дело в моей дислексии, эмоциональном напряжении в момент написания комментария, а так в же чрезмерном доверии встроенной проверке орфографии. Ответ на вопрос: похоже выбирает рандом.
Эта статья вызвала у меня очень сильный эмоциональный отклик, буквально "Вьетнамские флешбекти" со времен, когда я только начинал свою карьеру разработчика.
Это было 15 лет назад, и мне больно от того, что за это время мы пришли к тому же самому. Извиняюсь за тон - эти темы важны для меня на личном уровне; в конце концов, эмоции - это часть, которая делает нас людьми.
Вот несколько вопросов и моментов, которые я хотел бы обсудить.
В заголовке написано: "Нам не нужны кодеры". Вам - это кому? Тем, кто сам не способен стать ни кодером ни инженером, но зато уже готов требовать это с других, повышателей уровня инженерной культуры, стандартизаторов и прочих "эффективных менеджеров"? Без сомнения, кто-то все таки должен делать реальную работу, а не просто требовать ее с других. Вы пишите "Отвечать за результат, ... быть готовым нести ответственность, не деля её" и тут же перекладываете все на разработчиков, дескать это они должны меняться и брать ответственность, но не вы. В древности, ровно в то время, когда не было, как Вы выражаетесь "узкого разделении труда", было такое слово - лицемерие.
Что касается узкого разделении труда - это не прихоть программистов. Просто сложность и количество информации выросло в разы за 20 лет, и освоить сразу все на хорошем уровне практически невозможно. Это закономерный и, в некотором смысле, правильный процесс. Вслед за сложностью растет и время, требуемое на изучение и подготовку, а значит времени остается меньше на изучение всяких других полезных и интересных тем. Мне грустно от того, что такие очевидные вещи приходится расписывать. Времена "мастеров на все руки" прошли. Вы можете в одиночку сделать кирпич, но не можете построить небоскреб.
Вы пишите: "глубокая специализация начинает тормозить IT-производство" - это просто вранье. Наоборот, процессы распараллеливаются, все ускоряется. История это доказывает: продуктов больше, релизы чаще, готовые решения на любой вкус - вот что Я вижу вокруг.
Эта проблема - просто Ваша выдумка чтобы оправдать очередное бессмысленное словоблудие, стандартизацию стандартов, спецификацию спецификаций, стандартизацию спецификаций и прочий эффективный менеджмент.
T-shaped культура и прочая чушь пригодна только для "соевых инженеров", бегающих по конференциям про одно и то же, и бесконечно цитирующих одну и ту же книгу, но с других требующих T-shaped компетенций и разбираться во всем на свете. Попробуйте почитать Таненбаума или Кнута - там 7 томов, а не 400 страничек, как у Эванса. Нужны годы чтобы освоить это в совершенстве. Или это только программисты\инженеры должны прочитать и Кнута и Эванса, а великим "стандартизаторам" можно обойтись чем-то одним?
Выше уже замечали, но я не могу обойти этот вопрос стороной. Что такое "Ответственность", о которой Вы пишете, для наемного программиста? Я понимаю, что такое ответственность для владельца - ты принял плохое решение, ты потерял деньги, принял хорошее - получил. А для наемного работника это как? Будете делиться прибылью пропорционально успеху компании или это просто красивые слова и очередная брехология?
Что касается стандартизации, с одной стороны у вас стандарты стандартизации, а с другой Вы пишете про "Выход за рамки", "Инициативность" и "Развитие". Вам не кажется что одно слегка противоречит другому, а истинное "Значение стандартизации" = 0?
Вы пишите: "давайте уже избавимся от образа разработчика как какой-то «биомашины»", но тут же пытаетесь навязать им(нам\мне) какие-то стандарты работы, как у Вас уживается в голове это противоречие? Я - уже не биомашина, от того, попытка надеть на мою сферу очередные "стандартизации" вызывает у меня (и судя по комментариям - не только у меня) некоторое негодование.
Что касается ChatGPT, когда Вы говорите молодым сотрудникам: "скоро тебя заменит какой-нибудь ChatGPT" - это ложь и манипуляция. С самого начала карьеры я слушаю как меня заменит более сильный прогер или более молодой, или теперь ChatGPT. Только вот, как показывает эта статья, любители заменять программистов не способны даже статью без противоречий написать, не то что ТЗ для человека. А уж требования для GPT должны быть еще более проработанными.
Вы говорите о "Коммуникации", но это работает в обе стороны. Почему только прогер должен "общаться с бизнесом, общаться с коллегами", а не наоборот? Может было бы лучше, если бы и со стороны бизнеса было умение общаться с программистами? Интерфейс известен: Техническое задание. Ах да, без прогера же никто не способен его составить (иначе зачем Вы предлагаете разработчикам заниматься и аналитикой?).
В заключении, пока разработчик, или как вы в унизительном ключе выражаетесь, кодер, не напишет код, все ваши потуги бессмысленны. Идея же заставить программиста и анализ провести, и аналитику и ТЗ себе написать, сделать самому, и потестировать еще - не нова. И не полезна. Вы пишите, что скучаете по тому, как было раньше (раньше было лучше, да?). Это буквально анти-развитие и анти-прогресс. Не надо так.
Я бы хотел обсудить следующие 3 утверждения:
1. Нет никакого "Go-to-Market Framework" - разрозненный набор действий в сфере маркетинга не является фреймворком ни в каком понимании.
2. Нет никакого "Product Development Framework" - есть много разных, хороших и плохих, подходов к продуктовой разработке, часть из которых можно назвать фреймворками, но конкретно в этой статье не имеется ввиду какой-то конкретный из них (если имеется - то какой?), а обобщение используется как частное, в силу непонимания автором контекста и наплевательского отношения к тексту и читателям.
3. Эта статья - прекрасный пример того, как нейросеть может нагенерировать бредятину на любую тему и подтвердить и развить практически любое утверждение, даже бесконечно оторванное от реальности.
Вы не указали ИНН, потому что нет никакой компании. Ваши примеры - выдумка, а Вы - просто врёте.
Укажите пожалуйста ИНН или хотя бы название этой отдельной компании, а то может сложиться впечатление, что никакой отдельной компании нет. Я бы не хотел, чтобы кто либо заподозрил Вас в обмане.
Как пропатчить KDE под FreeBSD?
Вот Вы пишите: "У нас с помощью ТРИЗ была создана отдельная компания", уточните пожалуйста, а как называется эта компания? А то, вот, я захожу на сайт "РЕКОНН", и первым пунктом в меню вижу телефонию, и никакой отдельной компании не вижу.
Нет, не тон. По тону мне всё нравится. К тому же, я люблю списки, а в статье много списков. "Покоробила" меня именно суть.
В статье описаны процессы всплывания проблем, а тут Вы говорите о ленивых сотрудниках (а ниже еще говорят про делегирование ответственности) - и это слегка подмена понятий. Ленивый сотрудник может (и скорей всего будет) вообще умалчивать о проблемах, и напротив, до последнего говорить что "все хорошо, прекрасная маркиза", потом будет что-то вроде "почти доделал, завтра будет", и только потом "ой, вскрылись непредвиденные обстоятельства". Против этого есть другие инструменты - подписанные коммиты, фактически закрытые задачи, и прочее. Так же как и очень ответственный и трудолюбивый человек тоже может прийти с проблемой. Обходиться с теми и с другими одинаково, наверное неправильно. Так же как и считать, что все кругом д`артаньяны, и только один руководитель в белом пальто стоит красивый.
К тому же, если честно, я не совсем понимаю, что значит "ходить со своей проблемой ко всем остальным" с Вашей точки зрения. По контексту я вижу будто бы это тоже самое, что перекинуть свою работу на другого. Но. Вот допустим, есть у меня задание, напрограммировать систему скидок, или там, картину нарисовать. И я такой: "Не буду рисовать, пусть Вася рисует" - наверное тут надо обсуждать увольнение, а не подумать и погуглить. Или вот, когда руководитель на подчиненных сваливает принятие решений - это уже не "обезьяна", а делегирование, и "вы не понимаете, это другое"?
В статье представлен несколько однобокий подход. Я бы предложил:
1. Рассматривать (и организовывать) процессы решения проблем и обучения отдельно друг от друга, а не мешать все в кучу (это главное, что меня "коробит").
2. При разборе проблем учитывать более широкий контекст, в частности:
- учитывать не только квалификацию, но и специализацию (если я программист, а Вася из моего примера - художник, всё резко переворачивается);
- учитывать добросовестность работника и исторические обстоятельства;
- учитывать уровень загруженности работника, его уровень стресса и ментальное состояние;
- вместо "указать о пробелах в сфере самостоятельности", вносить решения в должностные инструкции и программы обучения;
- дополнить этот список.
Отдельно хочу сказать, что я разделяю Вашу боль и искренне Вам сочувствую. Однако, если рассмотреть абстрактную, не относящуюся к кому бы то ни было ситуацию, при которой должностных инструкций нет или есть только формально, внутреннего обучения нет или есть только фикция, оценки персонала нет или есть только 360 для галочки раз в год, проверки компетенций нет, матрицы компетенций нет, бизнесс-процессы не настроены, зоны ответственности четко не определены - наверное корень проблем в ленивых смекалистых сотрудниках. Это уже моя боль.
Нахожу этот подход чрезвычайно вредным и токсичным. Не лезьте к господину диванному управляющему со своими мелочами, а если не ваша зона ответственности - вообще забейте.
Про уровень проблемы конечно красиво. Только вот пара моментов:
1. Эти "уровни", они как-то определены и зафиксированы? Скорее всего нет. Более того, то, что сегодня не очень важно, завтра может оказаться очень важным. Без конкретных критериев, в лучшем случае - рассуждения в пустоту, а в худшем - попытка управляющего слить вниз свою главную задачу - принятие решений.
2. Вижу в этом одну из манипуляций "менеджера-совы", на которую часто попадался, будучи молодым и зеленым. С одной стороны "разбирайся сам со своими проблемами", а с другой "почему не сказал, если видел проблему" - итог: только моральное угнетение, потеря мотивации и лишний стресс для работника - это буквально потеря денег.
Что касается рекомендаций для "миддл-специалиста": "каждый раз спрашивать о их видении решения" - Вам результат нужен или в учителя поиграть? Если на обратную связь работник часто будет получать ответы уровня "иди сам подумай" или, б-же упаси, уроки и поучения о "пробелах в сфере самостоятельности" - просто больше не будет никакой обратной связи.
Устраивать формализаторство вместо коммуникаций, оставлять работника наедине с озвученными проблемами, забивать на проблемы, которые напрямую тебя не касаются - это буквально управление наоборот. Не рекомендую.
Рекомендую вот что:
1. Выстраивать открытые и доверительные отношения между работником и руководителем. Да, злоупотребления надо пресекать (желательно на этапе найма). Но в остальном, если работник приходит с проблемой, пусть даже в своей зоне ответственности, обычно это не спроста - стоит разобраться, стоит поддержать. Особенно в it сфере, где моральный настрой и уровень стресса очень сильно влияют на производительность.
2. Поощрять развитие коммуникаций как между работником и руководителем, так и между работниками, поощрять погружение не только в свою область ответственности, но и в смежные. Развивать культуру честности, особенно при обсуждении проблем, через открытость и безопасность.
3. Минимизировать моральное давление и унижения, категорически исключить "гуру-наставнический" тон, "прокачивание мышления вопросами" и прочие проявления комплекса неполноценности. Прямое обучение - да, введение регламентов - да, корчить из себя всезнайку и великого мастера кунг-фу, только потому что ты на ступеньку выше - нет.
4. Поощрять взаимопомощь внутри команды, создавать атмосферу взаимной поддержки и "чувства локтя".
5. Создавать безопасную среду, не только с физической, но и ментальной точки зрения. Жестко следовать декларируемым моральным принципам. Особенно это касается руководителей.
Ого! Оказывается, разработчики тоже люди, у которых бывают плохие и хорошие дни, а внутри направлений бывают более узкие компетенции и непереносимый опыт. Вот это да, кто бы мог подумать, вау.
Мне пришлось плотно поработать с Битриксом, к тому же вечер пятницы, и мне есть что сказать! Вот мои не "типичные аргументы о недостатках платформы":
Инфоблоки без сомнения являются "сердцем" Битрикс, на них построено очень много решений, в частности каталог товаров в стандартных компонентах магазина. Чтож, попробуем создать инфоблок, заполяем замечательные поля NAME, CODE, IBLOCK_TYPE_ID и т.д.
А потом попробуем получить инфоблок - по названию (NAME) находит, по коду (CODE) находит, а по типу (IBLOCK_TYPE_ID ) - нет. Ну как так? А оказывается, для фильтра по типу нужно использовать ключ TYPE, а не IBLOCK_TYPE_ID. Почему, а главное, зачем?
О, документация, любимица всех битриксойдов! Получение списка элементов инфоблока, чуть ли не основной метод Битрикса - в первом же примере кода ошибка.
Описание части методов вообще утрачено, пример.
Придумали D7, несколько лет назад, до сих пор создать элемент инфоблока нельзя. Зато у нас "ко-пилоты" и BI-аналитика в последнем обновлении.
Про обновления, кстати. В статье ошибкой номер 1 указано "создание самописных компонентов". А вот без самописных компонентов на чистом Битрксе, да на том же Аспро - ставишь обновление - пропадают цены у товаров. Купить ничего нельзя, в корзину добавить нельзя, все товары недоступны - это так называемая обратная совместимость. Каждое обновление как пороховая бочка - сперва на тесте, потом на тесте теста, потом тестирование теста... ну вы поняли. В итоге придумали параметр "COMPATIBLE_MODE", везде пойди проставь, при обновлении-то нельзя автоматически это сделать.
Или вот, хочешь например сделать в инфоблоке свойство-привязку к разделу. Например что бы показывать сопуствующие товары для элемента, или комплектующие какие-нибудь - к этому же инфоблоку товаров привязать нельзя через админку. Ну почему? А потому что если ты вдруг это сделаешь, сломается непонятно что непонятно где, т.к. часть стандартных механизмов не умеет работать с отдельными свойствами-разделами, а сразу по всем смотрит. Ладно, делаешь отдельный инфоблок "сопутки" - так в некоторых компонентах нельзя 2 инфоблока выбрать\подключить.
Компанию по email получить нельзя... Email и телефоны в отдельную таблицу засунули, ладно многие-ко-многим, понятно. Но почему в эту же таблицу засунули и Email-ы контактов и лидов, всё в кучу.
Или вот еще, допустим, была у вас на сайте форма, создающая лиды в портале. Простой понятный процесс - форму заполнил, лид создался. Обновляешь портал - файлы из формы не грузятся. А почему? Потому что выпилили загрузку файлов в лидах! Как говорится в статье, "встает вопрос «Кто виноват?» "...
Ух наболело, разошелся я что-то. Вот вам последняя загадка.
Как называется таблица в которой хранится URL сайта (для многосайтовости)?
Варианты:
1. b_site
2. b_url
3. b_domain
4. b_lang