Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач. 

Если спросить любого начинающего исследователя этой темы «А зачем нам оценка?», он скажет, что постоянно задают вопрос «Когда вы выполните эту задачу?», на который и надо ответить с помощью этой оценки. А что, если сам вопрос задан неверно?

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

• MVVM
• Inversion of Control
• Dependency Injection
• Service Locator

Так же вы узнаете как можно применять ViewModel вместе со своими стейт менеджерами (Bloc), избавив свой виджет от ненужного.

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.

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

О неприступные стены удобной архитектуры растущего приложения сломано много копий. Это, в принципе, довольно предсказуемо. У всех нас свой бэкграунд, опыт разработки и способ работы с абстракциями. Что для одного чисто и понятно, для другого может быть сумбурно и перемешано. Я хочу рассказать о том выборе, который был сделан год назад и который за эти месяцы себя прекрасно показал.

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

За свою карьеру я вырастил многих тимлидов как руководитель и ментор. За это время собрал обширную коллекцию возникающих во время работы проблем. Собрал список тех, которые встречались мне чаще всего. 

Сценарий: Определение причин слабой распространенности Gherkin
  Допустим я решил разобраться, почему Gherkin используется небольшим количеством команд
  Когда начал анализ причин
  Тогда понял, что неверно выбрана целевая аудитория

Gherkin был создан, чтобы сценарии использования можно было редактировать как нарратив (повествование), т.е. “почти на человеческом языке” в простой, лаконичной форме и доступном формате. Т.е. назначение формата было — быть в первую очередь лицом к не-технарям, но при этом сохранить более-менее достаточную формальность, чтобы можно было автоматически обрабатывать.

При этом бизнес-аналитики или любые другие конечные пользователи не очень хотят читать и тем более редактировать сценарии на Gherkin. Таким образом создание feature файлов перекладывается на плечи разработчика, для которого Gherkin — дополнительный и, возможно, лишний слой абстракции. Как мы знаем, “абстракции текут” и дополнительный слой только увеличивает вероятность “протечки”.

Может все же использовать языки, которые больше повернуты лицом к программистам?

Привет! Меня зовут Иван, я занимаюсь бэкенд-разработкой в Ozon: пишу микросервисы на Go для личного кабинета продавца. В прошлом году мы запустили новый процесс регистрации продавцов, в котором задействовано сразу несколько микросервисов. В нём стало больше шагов, при этом каждый из них выполняется в разных микросервисах. Поэтому мы задались вопросом: «А что будет, если один из шагов упадёт?».

В микросервисной архитектуре давно известен инструмент решения подобных проблем — это паттерн Saga. Мы решили взять его на вооружение и немного упростить под нашу задачу. Я расскажу о том, как мы это сделали, и покажу, что Saga может быть простой. Так что если вы давно хотели попробовать реализовать Saga, но вам казалось, что это сложно — читайте дальше.

Привет, Хабр! Меня зовут Капитолина Кузнецова, я Ruby-разработчик и на своём текущем месте работы в Купере (ex СберМаркет) доросла до роли тимлида. За 2,5 года я, так сказать, освоилась в этом статусе и, если верить моей команде, руководитель из меня получился неплохой, но вьетнамские флэшбэки о своих первых месяцах работы в новой роли ещё свежи.

Быть начинающим тимлидом — это...

- когда встречи занимают по семь, восемь, а то и девять часов подряд;

- когда ты целый день что-то делаешь, дико устаешь, а в конце не видишь никакого результата;

- когда о Jira знаешь больше, чем о собственной семье, а встречи с друзьями планируешь на новогодние праздники 2025 года.

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

Когда вы вступаете в должность в качестве руководителя или старшего менеджера проекта, одной из первых и самых важных задач является понимание текущих процессов управления проектами. Этот процесс, часто называемый аудитом, позволяет определить точку «As Is…» — текущее состояние дел в компании. Без четкого понимания текущей ситуации невозможно разработать эффективный план действий и начать внедрение улучшений. Меня зовут Саша Максимова, я уже 10 лет занимаюсь развитием команд и управлением проектами, сейчас работаю в Kokoc group на должности Руководителя отдела управления проектами и надеюсь, эта статья поможет многим избежать моих ошибок.

Классно, когда в компании уже есть механизм оценки требований или оценку ведут архитекторы / PM-ы / PO и прочие люди, которые никак не являются аналитиками. Но у нас в компании не было сложившейся модели оценки, и каждая команда тратила большое количество времени, оценивая запросы клиентов. Тогда нам пришлось разработать собственную схему оценки требований, потратив на это много времени - сначала набирая опыт и проверяя его, затем внедряя и объясняя сотрудникам методику.

Сразу же скажу вводную по предметной области - у нас была готовая система с узкими местами по реализации, и много разного консалтинга вокруг фич по доработке (т.е. большинство фич требовало методологического подхода и можно было как реализовать "в лоб как написано", так и предложить клиенту использовать уже готовые вещи в системе, но не так, как звучит его требование).

Еще нужно отдельно оговорить то, что запросами у нас в Компании занимались в-основном аналитики не потому, что они знают, сколько занимает реализация каждой фичи, а потому что технические специалисты (разработчики и архитекторы) хотели детального описания того, что нужно будет разработать. Так как фичи в большинстве своем были плюс-минус похожи (доработать карточку, сделать процедуру и т.д.), аналитик мог на основании своего опыта и наших подсказок для оценки проставить нужное число часов разработки. За сложными и новыми вещами, конечно, аналитики обращались за помощью к архитекторам.

Ниже я расскажу, какую схему мы стали применять для оценки требований.

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