Comments 20
Что стало с той компанией, где начались внедряться идеи Голдратта и его ТОС (теории ограничения систем)? Стало лучше или стало хуже?
У той компании, где я увидел её, вроде бы всё хорошо. Кстати, я подсмотрел у них интересную идею: бить бизнес на бизнесы, чтобы внутри компании формировались собственные денежные потоки. Забавная штука — она позволяет привязать всех к цели и видеть реальную эффективность отделов: кто сколько приносит и сколько нам это стоит.
Потом было 5 лет CTO — последняя ссылка про это. Но там я довольно быстро пришёл к осознанию: бутылочное горлышко вовсе не в IT, а то, что действительно нужно менять, — за рамками моего влияния.
А из TOC я забрал логические инструменты. На удивление, всё это очень похоже на архитектурные подходы и принципы проектирования эффективных систем. В общем, тем TOC и занимается — исходя из одного простого постулата:
Любые модули системы будут стремиться увеличивать свою автономность и достигать своих (локальных) целей, если специально ничего не делать.
И отсюда следует:
эффективная система ≠ сумма эффективных модулей — даже наоборот.
Для общей эффективности может потребоваться локальная неэффективность.
Так что, к моему удивлению, одна из лучших книг по системному анализу — вовсе не про IT.
Грозовая туча — инструмент для решения архитектурных задач.
Дерево текущей реальности — способ описания текущей архитектуры.
Дерево будущей реальности — способ проектирования новой.
Инженерная работа — это и есть способ внедрения этих идей в жизнь.
Бутылочное горлышко вовсе не в IT, а то, что действительно нужно менять, — за рамками моего влияния.
Бутылочное горлышко почти всегда находится в неэффективных бизнес-процессах. Изменить существующий бизнес-процесс достаточно сложно, т.к. требуется изменение поведения большого количества людей, поэтому имеет смысл всё делать постепенно, давая людям время привыкнуть к этим изменениям, после чего можно продолжить внедрять новые изменения. Также надо задавать себе вопрос, а что это изменение даст этим людям. Станет ли им проще работать? Начнут ли они получать больше удовольствия от работы? Польза для компании – это хорошо, но не надо забывать про людей, ведь если они не увидят в изменениях пользы для себя, то будет большое сопротивление любым изменениям.
"одна из лучших книг по системному анализу — вовсе не про IT."
Там несколько книг в серии Цель. Одна из последних рассказывает про розничный бизнес, т.е. сферу продаж. Книга про проект DevOps показывает как всё это применимо к производству. Так что да, принципы универсальны и их можно использовать не только в IT.
Дерево текущей реальности и Дерево будущей реальности.
Единственные штуки, которые я так и не осилил. В книге написано нормально, но на практике мне самостоятельно ни разу не удалось их построить. В результате решил их не использовать, т.к. другие практики ТОС и бережливого производства всё равно позволяют добиться выдающихся результатов.
Если не читали ещё книги Донеллы Медоуз по системному мышлению, почитайте, вам наверняка будет интересна её методология описания систем. На мой взгляд, она дала лучший способ описания бизнес-процессов как цепочек (петель, колец) причинно-следственных связей.
Классный пост! Интересно
Идея дробления бизнеса из большого на части она очень стара, и основная ее цель снижение налоговой нагрузки. Но это очень опасная штука и может привести к штрафам от налоговой https://secrets.tbank.ru/buhgalteriya/riski-drobleniya-biznesa/?utm_referrer=https%3A%2F%2Fwww.google.com%2F
Видимо, вы дошли до края ограничения в компании или в профессии. И решили сменить одно и/или другое.
Серьезная, глубокая статья.. Есть чему поучиться. Я тоже из Томска.
Спасибо, в общем для этого и поделился. Так как заметил что статья о чужом опыте гораздо полезнее чем статьи о том как кто-то пишет как что-то делать правильно.
Потому что у всех всё по-разному, а так каждый может подчерпнуть что-то своё.
Ну и да, Томск это похоже it колыбель Сибири, для меня, не знаю как сейчас, но раньше был очень много it компаний
Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес
Так вы для себя эти вещи делали? значит в IT вы вообще не были на тот момент, просто проявляли интерес к технологиям и занимались интересными вам делами. странная тенденция козырять школьными\универскими увлечениями как опытом в IT
Всё, что раньше я считал говнокодом — перестало им быть.
А как это получилось? Как код со временем становится говнокодом - это понятно. Постоянный, можно сказать, процесс. А обратный случай? Просто я не представляю.
Да, код может работать, но ведь от этого он не перестаёт быть плохим? Да, предположим, в нем может быть заложены выдающиеся паттерны и гениальные идеи... но они могут быть плохо реализованы и плохой код не становится лучше из-за внезапно обнаруженной глубины...
Всё что ниже это конечно-же ИМХО:
Автор изменил своё отношение к коду, который видит. Или, чуть другая формулировка: своё восприятие результата работы других программистов.
"Плохой" – оценочное суждение, имеющее различное фактическое наполнение у разных людей и в разных ситуациях.
Я со временем сознательно стал двигаться в сторону меньшей критичности в оценках. Да, архитектура кривая. Да, тестов нихрена нет. Да, вместо нормальной векторизации три вложенных цикла.
Но этот код сделал мир лучше? Помогает ли он реально людям жить и работать, и стоит ли техдолга? Ведь если альтернатива - пять лет медитаций в Шаолине, чтобы построить идеальную абстрактную фабрику - оно точно надо? Ведь программирование - не только (и даже преимущественно не только) про решение хорошо формализованных задач, оно ещё и про понимание устройства самой задачи и мира в целом. Поэтому у всякого кода есть жизненный цикл, и, хотя за кое-какой тяп-ляп всё равно надо руки отрывать, в целом неидеальный код, но быстро, часто лучше, чем хороший, но долго. Нет смысла полгода задрачивать задачу, которая нужна чисто для аналитики/принятия решения и пишется на коленке за вечер. Плохо только, если этот код потом на годы укореняется в продакшне, и за это время не выделяется ресурсов на рефакторинг.
Вообще стараюсь больше хвалить других (и себя тоже). Перфекционизм - зло.
'QA не мешали релизам' - когда цель не поставить качественный продукт, а побыстрее отчитаться о работе
Автор, если тебя посадить за разработку какого-нибудь более менее алгоритмически сложного процесса в реальном времени - ты поплывешь еще на этапе, что не сможешь понять математику предметной области.
Все эти истории про великих дедов-архитекторов корпортативных приложений не впечатляют потому, что всех их знаний можно добиться за 5 лет, в отличии от настоящих инженерных задач, где можно десятилетиями копать вглубь. Это не предъява - я сам такой. Просто стараюсь не усложнять простые вещи. Сейчас наверное лучше за здоровьем следить. Удачи.
Как я стал программистом и перестал им быть