Управление разработкой *

Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts».

Вы создаете новую систему, и два члена вашей команды предлагают альтернативные архитектуры для отправки уведомлений. Какая из них правильная?

Первый разработчик предлагает модель push: ограниченный контекст должен дать указание Notifications отправить уведомление. Notifications должен просто подчиняться командам и отправлять указанные уведомления.

Второму разработчику не нравится модель push-уведомлений, и он предлагает решение на основе хореографии: когда ограниченные контексты создают события, Notifications должен подписаться на эти события и определять, когда отправлять уведомление.

Как бы вы спроектировали решение? Что еще более важно, как бы вы приняли это решение в команде? Как вы будете разрабатывать наиболее эффективную архитектуру, которая поддерживает краткосрочные цели и долгосрочное развитие?

Если предприниматель планирует производить приборы, станки или гаджеты - этот вопрос будет одним из первых. Обычно люди недооценивают затраты на разработку, производство и масштабирование нового электронного аппаратного продукта. По этой причине подобные стартапы часто терпят неудачу: либо кончаются деньги ещё до выпуска продукта, либо оказывается, что проект изначально не являлся прибыльным.

 Проблема следующая: разработка «железки» состоит из нескольких этапов. Они слабо связаны с друг другом и требуют участия специалистов различных профилей: инженеров-конструкторов, промышленных дизайнеров, UI/UX дизайнеров, электронщиков, программистов, производственников и прочих специалистов в зависимости от предназначения продукта. При этом оценка стоимости разработки, материальной себестоимости изделия и стоимости производства – три главных критерия. С их помощью можно определить: будет притягивать проект инвестиции или приносить прибыль, или нет.

Обычно предприниматели еще до начала проекта начинают считать потенциальную прибыль от своего революционного продукта. Когда дело доходит до подсчёта расходов на разработку и производство, наступает ступор. Затем приходит понимание: чтобы кто-то посчитал все вместо тебя, необходимо предоставить внятное описание продукта с указанием точных технических характеристик, алгоритмов работы, условий эксплуатации и прочее. Иными словами, нужно составить грамотное ТЗ.

 В нашей компании мы часто сталкиваемся с такими запросами: "разработайте нам нечто такое, чтобы прям вау". Иногда к ним прилагается эскиз на салфетке и комментарий: "хотим таких тыщу штук в год".

• Автоматизированное управление конфигурацией, тестированием и развертыванием приложений;
• Контроль версий для обеспечения совместной работы и откатов;
• CI для автоматизации сборки кода и обеспечения высокого уровня обратной связи за счет более частых выпусков ПО с меньшим риском.

Рядовой случай: заказали сайт, web-студия его разработала, протестировала и успешно сдала проект, а в течение гарантийного срока (3-6 месяцев) исправила баги. На первый взгляд все в порядке. Что еще нужно?

Но бизнес не стоит на месте, возможно уже завтра потребуется добавить новый функционал или раздел. Можно конечно заказать доработку. Однако, на практике, если нет своей команды, готовой этим заниматься все может пойти не по плану. В данной статье на примерах разберем что должна включать техподдержка сайта и нужна ли она вообще.

Уже более 17 лет я, тем или иным образом, занимаюсь внедрением и разработкой программного обеспечения. Значительная часть моих решений предназначена  для моих клиентов в России и  за рубежом. Все они связаны с вопросами автоматизации и оптимизации работы компаний. Одной из важных проблем при таком сотрудничестве всегда оказывается вопрос,  с чего начать и как понять, из чего состоит предприятие.

Я перепробовал разные способы, и почти всегда при этом работал по процессной модели. Мне ставили определенные задачи, я описывал один, два, три процесса, и, в принципе, всех это устраивало. Но меня не покидала мысль о том, что есть всё-таки какая-то универсальная модель предприятия, которую можно использовать из раза в раз. И если для меня она со временем стала интуитивно понятной, то для людей, которые только начинают свою деятельность в этой сфере или не сталкиваются постоянно с автоматизацией, а потому не имеют такого опыта, как я, конечно, возникает множество вопросов, Большинство из них связаны с тем, с чего начинать работу, как и что в каждом из случаев внедрять, и вообще, как строить свое сотрудничество с клиентами и зарабатывать в этой сфере. 

В связи с этим я решил описать, то есть создать некую почти универсальную модель. Я к ней шёл уже, наверное, лет десять.Конечно, я не занимался ее разработкой все это время. Но уже  десять лет назад у меня были первые, скажем так, черновики такой модели.

Парное программирование, конечно, имеет много положительных сторон, но также оно требует практики и не всегда поначалу проходит гладко. Перечислим некоторые традиционные подводные камни и дадим несколько советов, как с ними справиться. Когда сталкиваетесь с такими проблемами, держите в голове свою цель. Важно помнить, чего вы хотите добиться, чтобы держать всё под контролем.

Ты написал код, отправил его на ревью. Во время ревью тебе указали на ошибку в коде и вернули задачу на доработку. Или текст, отправленный на проверку, получил фидбэк о пропущенной запятой или орфографической ошибке. 

Рассуждаем о том, почему не стоит сразу исправлять ошибку и отправлять на повторное ревью. Призываем делиться своим мнением по вопросу в комментариях.

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Автоматические личные кабинеты и чат-боты

Часть 5: Автоматизация на производстве

Часть 6: Траблшутинг на предприятии

Часть 7: Интуитивная система управления качеством (в этой публикации)

Вы часто доверяете своей интуиции и внутренним ощущениям? А как научить систему действовать интуитивно, полагаясь только на неактуальные данные? Об этом и не только, на реальных примерах, далее в статье.

Наукоемкое производство в наши дни нельзя представить без применения самых новейших методов управления и бизнес-инжиниринга.  Если еще каких-то лет 15 назад наукоемкое производство в России почти отсутствовало, то сейчас в этой сфере наблюдаются подвижки, а значит растёт потребность в применении методов его управления и анализа. 

А чем оценивается эффективность бизнес-процессов? Правильно, общей ценностью для предприятия, а также конкурентоспособности используемой технологии. Именно от этого зависит достижение всех показателей, важных для удовлетворения целей бизнеса. 

В посте я расскажу про методы повышения качества, которые сейчас получили особую популярность — построенные на основе методологий Lean Six Sigma, а также обсудим гибкие методики на основе подходов Agile и гибридных подходов PRINCE2. Разберу плюсы каждого из подхода и разберу необходимые шаги и условия для их внедрения.

Всё это в разрезе создания ПО (также подойдет и для производства радиокомпонентов).

Cпустя три недели после выхода на работу, мой новый программист пишет такой же код, как и трое моих других опытных разработчиков, которые на том же проекте около года.  В свою очередь эти трое создают единую архитектуру, дают одинаковые названия сущностям и пишут чистый код, что сильно упрощает проведение code review и облегчает всем понимание кода.

* В статье пойдет речь о кейсе трансформации компании, чье название в этой статье нельзя упоминать. Но чтобы вы все-таки чуть лучше понимали контекст, далее в тексте я буду использовать термины "Красно-белый оператор" (КБО) и его банк (КБО Банк)

Для начала, думаю, будет нелишним начать с предыстории и предпосылках начала трансформации КБО.

Итак, в начале 2019г. КБО принимает стратегию трансформации компании в продуктовую экосистему. Что это и зачем?

Технический долг — головная боль многих разработчиков. Это та ситуация, когда ты видишь, что можно сделать лучше, но не делаешь этого из-за высокой нагрузки, малого количества времени и ещё по тысяче причин. В итоге долг накапливается, накапливается, накапливается... А потом что-то происходит.

Как сделать так, чтобы иметь возможность разгребать технический долг, поговорим в этой статье.

«Всё, договорились, скрам-мастером теперь будет Полина», — отлично, кто-то договорился о том, что я буду скрам-мастером. Отрицание, гнев, торг, депрессия, принятие.  

Привет, меня зовут Полина, и я — системный аналитик. Некоторые компании нанимают отдельных обученных скрам-мастеров для более эффективного ведения и мониторинга процессов внутри команд разработки. Но на такой путь готовы не все. Более распространен подход, где скрам-мастер выбирается непосредственно среди участников команды разработки, и сотрудник совмещает свои прямые обязанности и скрам-мáстерство. В этой статье я не буду рассматривать плюсы и минусы каждого из подходов, но расскажу о том, а что же, собственно, делать, если скрам-мастерство пришло к тебе, а ты не был к этому морально готов.

Философы давно доказали, что представление о предмете или явлении зависит от точки зрения автора, и выскочить из этого круга довольно сложно — наш жизненный опыт напрямую влияет на оценку происходящего. 

Всем привет, это снова Макс Кравец, CEO IT-компании Holyweb. Публикуя статью о зарплатах разработчиков, я хотел поделиться с окружающими собственным представлением о том, что происходит на рынке IT. Но это точка зрения бизнеса, а есть и другая сторона. Дискуссия, которая развернулась под статьей — настоящая «Карта Мародеров», показывающая, куда идет и о чем переживает каждый комментатор. Ниже — несколько тем, которые родились в ходе обсуждения и оказались интересны самим разработчикам. 

Дисклеймер: комментарии авторов приведены без изменений или с минимальным редактированием.

Она помогла нам переиспользовать игровые механики в непохожих проектах и увеличила скорость разработки на 25%.

Определение подходов к автоматизации бизнес-процессов и связанный с этим выбор конкретных технологий, особенно в крупной организации, - комплексная задача, которая требует учитывать экономические, организационные, функциональные, технические и другие аспекты. Сегодня на рынке существует множество BPM-технологий самого разного масштаба - от легковесных библиотек до крупных платформ. В этой статье мы подготовили сравнительный анализ двух очень непохожих представителей из разных областей этого спектра - Pega и Camunda. По каждой из этих технологий мы, ЛАНИТ - Би Пи Эм, накопили немалый опыт использования и наработали портфолио крупных корпоративных решений. Среди них есть проекты по автоматизации кредитных конвейеров и других бизнес-процессов в крупнейших банках РФ (Сбербанк, ВТБ, Альфа-Банк). Есть проекты как с монолитной, так и с распределенной, микросервисной архитектурой.

Если кратко, Pega - экосистема для IT-поддержки процессного подхода в бизнесе, а Camunda - набор инструментов для реализации процессных приложений.

Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

В этой статье я сделаю попытку объснить, каким образом формулируются идеи, которые являются самой сложной и самой ценной частью Impact Map, а также поделюсь своим видением, как наиболее эффективно воспринимать каждую из частей Impact Map.