Комментарии 7
Вроде бы прописные истины, но написано хорошо, читать интересно. Спасибо. На самом деле все сказанное относится практически к любому бизнесу и не только бизнесу. История про миссию и ценности последнее время весьма популярна, даже органы государственной власти придумывают себе красивые изречения и вывешивают под ведомственными гербами, но рядовые сотрудники часто не понимают какой вклад они привносят в достижение этих целей, а высокое руководство не до конца понимает проблемы на местах.
Пожалуйста!
Мысль очень верная! Всё сказанное можно перенести на взаимодействие любой коммерции и бизнес-заказчиков с любым производством. Спасибо за очень важный вывод!
Да, часто читая что-то я сначала думаю про себя «спасибо, кэп! Это же очевидно всё.». но потом появляется вопрос, а делаю ли я так как только что посчитал очевидным. А делают ли окружающие меня люди так? Анализирую это получилось выделить 4 стадии работы с прописными истинами.
Знать их
Вспоминать когда про них спросят / увидишь напоминалку и применять в моменте
Основываться на них в действиях без дополнительных напоминаний
Действовать не просто зная их как формулы, но понимая почему они появились и зачем это всё так работает
А для того, чтобы продвинуться от первой стадии к четвертой, важно дать возможность людям посмотреть на них с разных сторон и в разных примерах, чтобы было как можно больше возможностей увидеть в них то, что получится перенести на свой опыт не затрачивая сил на дополнительную абстракцию. Это в том числе назначение статьи и примеров в ней.
А на самом деле проблема одна — технический директор вовремя не обратил
внимание структуру проекта и распределение задач в целом, а бизнес не
сообщил о своих планах подключать всё больше внешних источников данных и
сервисов.
дочитал до этого места чуть со стула не упал, так как бывал в ситуации описанной выше со всех сторон, даже со стороны заказчика ставил требования и причина далеко не в CTO.
Очень часто то что делают как MVP или выбирая между сделать нормально за х времени или костыльнуть за у, причем y < x и выбирается решение естественно костыльнуть и вот такой зоопарк потом падает на поддержку, потом команда 2 в этот франкенштейн вкидывает еще костыли и франкенштейн начинает свою жизнь питаясь человека часами, но переписать естественно это нельзя потому что для этого надо бизнесу дать эстимейт по времени, но ты либо честный и говоришь что это нереально эстимейтить и говоришь сроки в месяцах и тебя естественно шлют либо что ?
И очень часто вместе с командой уходит и текущий самый "прошаренный айтишник", а вместе с этим и знания.
sad but true
Очень часто заказчики хотят управлять процессом, который они не хотят понимать и требуют привычные им метрики управления (сроки или другими словами цены) и исходя из этого получают ИЛЛЮЗИЮ управления. В каких то областях такой способ управления вполне работает (например производство), где все разбито на базовые типовые операции и там легко прогнозировать сроки, а в каких то областях это может не работать абсолютно, например разработка где каждая интеграция может иметь свои особенности и очень сильно отличаться и каждая интеграция это как первый запуск нового завода, в новом регионе, производящий разный продукт.
Чтобы изменилось если бы CTO вовремя обратил внимание на структуру проекта и распределение задач в целом, а бизнес ему сообщил о своих планах ?
НИ-ЧЕ-ГО
Спасибо за развернутое мнение!
Действительно если бы вопрос был только к СТО, то стоило бы задать мне дополнительный вопрос. Однако я указал что проблема и со стороны бизнеса в том числе. Это содержится в цитате.
И еще раз, да, очень часто заказчики хотят управлять тем, что не понимают. Но миссия инженера помочь бизнесу принимать верные решения, позволяя понять это на должном уровне абстракции, который позволит в явном виде синхронизироваться в целях. То о чем Вы пишите, кажется что выглядит как ситуация в которой разработчики не хотят вводить бизнес в тему, так как сложно/вы не поймете/мы на это не нанимались. А бизнес в свою очередь не готов послушать. И вот мы опять в той же ситуации - бизнес не готов послушать, а разработчики не объясняют.
И мой посыл, что либо обе стороны начинают заботиться о партнерстве, работая сообща и ради общих целей, либо имеем то, что имеем.
Да, такие ситуации встречал наверняка каждый.
Считаю что важно всем таким командам помнить, что доверие не появляется на пустом месте. О нём нужно заботиться и растить. Достигается это за счет открытости в постановке целей и в обсуждении причин и решений повлекших их за собой. За счет готовности каждой стороны поделиться, на понятном языке, сложностями и рисками и тд.
Без такого диалога, как Вы и написали, все продолжат сидеть по своим углам и шипеть друг на друга.
Новое всегда хорошо, особенно если есть спрос и поддержка.
Бизнес и разработка — как понять друг друга и подружиться?