EAccessViolation
Когда я был юн, я ненавидел архитектурное проектирование и документацию, и считал единым источником правды код. Если вы знакомы с мемом в заголовке статьи, то конечно же знаете, к чему это привело меня в конечном счете.
Эта история про то, как я пришел к необходимости процесса обязательного технического анализа по задачам для программистов.
В 2024 году на рынке существует довольно большое количество экосистем цифровых продуктов: как для B2C-сегмента, так и для B2B. И если просто в поисковике вбить «как создать экосистему», вы получите кучу статей от аналитиков, продактов, бизнеса. Однако, если попробовать сформулировать запрос с конкретикой по дизайну (например, «как создать дизайн для экосистемы продуктов»), мы получаем классную выдачу, в которой экосистемой называют дизайн-систему. И это ужасная подмена понятий, так как дизайн-система является всего лишь одним (хоть и очень значимым) из ингредиентов вкуснейшего экосистемного дизайн-борща.
Что же входит в этот борщ?
Часто противопоставляют проектную и процессную деятельность, хотя встречается «процессный подход при управлении проектами» и наоборот (путаница связана с неточностью термина «процессный подход»). «Процесс vs Проект» см. [Process24]. Проектная деятельность - как набор типовых процессов рассмотрена (формализована) во многих проектных Best Practice, причем значительно подробнее и объемнее чем «процессный подход»: управление бизнес-процессами, Business Process Management (BPM CBOK). Про проектное управление (проектный подход) написаны «тонны» книг и придумана масса стандартов: PMBOK, ISO 21500, PRINCE2 и др.
Здесь мы рассмотрим только различные подходы к организации организационной структуры организации при реализации в ней проектов (проектная деятельность организации). Ранее в Треугольник орг-структур компании. Часть 1 были рассмотрены базовые типы орг-структур: функциональная – процессная – матричная. Добавим конкретики и практики и приведём примеры реализации орг-структуры непроектной компании и ее Офиса управления проектами (Project Management Office, PMO), как виртуального (неформального), так и выделенного в орг-штатную единицу. В проектной компании типовые проекты реализуются обычно как регулярный процесс.
Не так давно мы Газпромбанке пришли к очевидному выводу: можно создать сколько угодно отличных продуктовых команд с прекрасными разработчиками, но когда над тобой нависает такая махина, как банк, со всей его безопасностью, регуляторикой и прочими «выкрутасами», с которыми придется иметь дело, глаза начинают стекленеть, руки опускаться, а TTM отрастать.
Всем привет, меня зовут Кирилл Гилевич, и я хочу поделиться историей о том, как в очередной попытке отстать от разработчиков мы создали Центр методологии IT-производства, которым я и руковожу. Хочу поделиться тем, как мы оптимизируем взаимодействие между командами, какие процессы для этого придумали и зачем вообще нужны методологи.
История началась с разбора использования ресурсов приложением, которое занимается проксированием. Обнаружили, что довольно много времени оно тратит на выбор маршрута (роута), и решили ускорить этот процесс. Описанная в статье оптимизация не требует каких-то особых вложений, усилий или условий, поэтому приведенный код можно забрать к себе и использовать без каких-либо чрезмерных вмешательств.
Когда люди, не знакомые с разработкой и процессами в ней предлагают свои фреймворки для измерения или улучшения эффективности, ничего хорошего из этого не выходит. Поговорим о том, почему ничего хорошего не может выйти и из метода McKinsey, которые решили, что придумали универсальный подход, и воодушевлены продвигать его в массы. А еще поговорим о том, как и зачем на самом деле стоит подходить к оценке продуктивности разработчиков, чтобы не сломать уже работающие механизмы.
Зачем создавать паровой мотоцикл?
Весь мир сейчас пытается продвигать технику в будущее. Ищут всё более экономичные, мощные и удобные двигатели. Мне же наоборот, захотелось заглянуть в прошлое и оживить забытые технологии. Посмотреть, как оно было и вообще начиналось. Окунуться в эпоху индустриального взрыва. И создать настоящую паровую машину. Техника прошлого очень сильно отличается от всего что мы сейчас себе представляем. Это ощущение и понимание трудно передать, но я постараюсь.
Привет! На связи Олег Казаков из Spectr.
Мы продолжаем публикацию цикла статей, где делимся опытом и наработками и рассказываем, из чего состоит DevSecOps и как его внедрить в процесс разработки.
В предыдущей части статьи я рассказал о том, что представляет собой процесс DevSecOps в целом, из каких этапов он состоит, и подробно остановился на первом этапе — Pre-commit Checks. Сегодня пришло время для обзора стадии Commit-time Checks и ее инструментов. Поговорим о каждом инструменте отдельно и расскажем, на чем мы все-таки остановили свой выбор.
Я пришла в проектный менеджмент, именно в продуктовую разработку, когда это ещё не было мейнстримом. А в данный момент изумляюсь тому, во что превратилась отрасль.
Куда делись мои старые коллеги? Умные ребята, горящие своим делом, которые и меня учили, и прекрасно справлялись со своими проектами. Куда делись люди, на которых я хотела быть похожей в профессиональном плане? У которых можно спросить и проф.совет, и обменяться опытом? И почему сейчас вокруг нет больше таких коллег? Почему более опытные по возрасту и стажу коллеги совершают ошибки незаинтересованных случайных новичков?
Постоянно всплывают такие вопросы. За время работы я сменила приличное количество компаний — все крупные, с большими разработческими и ИТ‑отделами. И начинала я работать в подобных же компаниях. Вот только качество проектного менеджмента стерлось со временем. И работать в такой среде достаточно неприятно.
Мало того, что коллеги не стараются делать хорошо. Они просто не стараются вообще что-то делать
Какие перлы мочат современные ПМ и к чему это приведет, по моему мнению — далее в этой статье.
Продолжаю серию публикаций про наши Java-онлайн курсы. Предыдущие посты
— Контроллеры на дженериках: пишем кода в 3 раза меньше
— Миграция Java Spring Boot на Kotlin
— Работа с документами в Java
Сразу предупрежу: точно так же, как в контроллерах на дженериках сами контроллеры не параметризируются, здесь мы НЕ БУДЕМ параметризировать сами классы тестов. Поэтому не спешите писать комментарии, не прочитав статьи, что это «Bad practice». По поводу усложнения кода заранее отвечу так же, как и в комментариях к статье про контроллеры — код тестов и их написание становятся проще, за счет усложнения инструментов (собственно на этом и строится разработка фреймворков и ООП). Можно считать приведенные здесь подходы слоем абстракции, праметризирующий подход популярной библиотеки AssertJ к сравнению объектов и расширяющий его на сравнение json объектов.
Кому интересно:
Всем привет! Меня зовут Бургомистренко Кристина и я — системный аналитик в компании заказной разработки Rubius. В этой статье я рассказываю про свой опыт проектирования и сравниваю несколько популярных инструментов для создания вайрфреймов, которые может использовать в своей работе бизнес/cистемный аналитик.
Многие Golang-разработчики пробовали работать с БД в Go, и у каждого — свои боли. В этой статье разберём библиотеку database/sql как безотносительно конкретной СУБД, так и применительно к YDB. Рассмотрим трудности эксплуатации при использовании драйвера database/sql на проде. А также рассмотрим, что мы делали для решения проблем.
Меня зовут Алексей Мясников, я — руководитель Application Team в команде разработки YDB. Я очень люблю git blame за то, что с его помощью можно проследить, как развивалась инженерная мысль с течением времени и немножко побыть в шкуре разработчика той или иной классной штуки. В статье я расскажу, как реализовать драйвер database/sql для распределённой базы данных, какие проблемы при этом придётся преодолеть и как менялся подход с выходом новых версий Go.
Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».
За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.
Поговорим как раз об этом — о том, что формирует культуру работы с Git: начнём с конвенций именования коммитов и закончим практиками работы в пуллреквесте. В конце статьи я поделюсь полезными ссылками на интерактивные обучалки, шпаргалки и гайды.
В статье я хочу рассказать об одной очень интересной теории разработки документации на системы и программы. Её авторы утверждают, что создали ни много ни мало «Великую Единую Теорию Документации» (The Grand Unified Theory of Documentation). Мы привыкли с опаской относиться к заявлениям о том, что кто-то обнаружил сокровенную истину и раскрыл её профессиональному сообществу. В теории изложены идеи и правила, которые мы встречаем в разных методиках разработки документации и сами применяем на практике.
Основная ценность этой теории не в том, что она раскрывает некое сокровенное секретное знание, а в аккуратной систематизации этого самого знания и в полезных советах по разработке каждого типа документа. Не скажу, что я на 100% согласен со всеми правилами, изложенными в теории, но в ней есть много полезных и рациональных мыслей. В любом случае, она стоит того, чтобы с ней ознакомиться.
Есть настоящие профи по управлению проектами или те гении, которые придумывают изящные решения для заказчика. Однако почти в каждом, даже самом многообещающем проекте рано или поздно возникают проблемы. Иногда эти проблемы принимают монструозные масштабы, и команда проекта уже не может справиться с ними самостоятельно. И я тот самый человек, который их решает. Как я это делаю - тема отдельной статьи. Почему практически каждый раз получается? Ответ прост: всегда полезен взгляд со стороны. Однако наступил момент, когда этого оказалось мало. Я вляпался в настоящий факап, и единственным выходом из него были переговоры.
