Я не добавляю поле в продукт только потому, что оно может пригодиться когда-нибудь
Каждое поле в продукте просит данные, создаёт исключения и требует поддержки. Я добавляю его только когда понятны решение, владелец и срок жизни.
Читать статью →Каждое поле в продукте просит данные, создаёт исключения и требует поддержки. Я добавляю его только когда понятны решение, владелец и срок жизни.
Читать статью →Почему две команды не ускоряют разработку без ясной границы изменений: как разделить ответственность, защитить общие контракты и заранее предусмотреть путь назад.
Читать статью →Как передавать задачу между отделами без возвратов: определить готовый результат, обязательные данные, владельца решения, сроки и понятный путь для исключений.
Читать статью →Как обновлять прайс-лист без ошибок: единый источник цены, дата действия, отдельные скидки, проверка черновиков и журнал изменений.
Читать статью →Изменение API начинается с границы обещаний: кому нужен старый контракт, как пережить повтор запроса и как увидеть операцию целиком.
Читать статью →Почему автоматическое решение должно показывать свои основания, владельца правила и понятный путь для исключения.
Читать статью →Какие признаки показывают, что компания готова перестать вести текущую работу в старой программе и перейти к новой системе без двойного ввода.
Читать статью →Чтобы важные изменения не исчезали среди срочных сообщений, нужна одна видимая очередь, понятный владелец и простой способ решить, что делать сейчас, а что — позже.
Читать статью →Начинать объединение данных нужно не с выгрузки. Сначала договоритесь, какие сущности будут общими, кто отвечает за их качество и как вы проверите результат на живом сценарии.
Читать статью →Владелец процесса отвечает не за программу, а за результат и исключения. Разбираем, как выбрать такого человека до настройки автоматизации.
Читать статью →