Pro процессы

Привет! Меня зовут Дмитрий. Я являюсь руководителем группы в IT‑компании. Если перевести на более доступный язык, то получится так: Team Lead Integration. Компания не самая крупная, но очень международная. Знаете, я никогда не любил и не понимал такое сочетание англицизмов и русского языка. Особенно, когда в него закладывается некоторая двусмысленность. Особенно, когда используется pro . Потому что в него можно заложить столько details, если вы понимаете, о чём я. Тем не менее, для своих размышлений такой оборот показался мне более, чем уместным, включая его двусмысленность. Возможно, истинной причиной стал тот факт, что этот заголовок придумался одной ночью, прям перед сном, и я очень боялся его забыть и не вспомнить на утро, и поэтому он полюбился. В любом случае, попробую разобраться и раскрыть то, что имею на этот счёт. Pro процессы. Хотя изначальная идея была в противопоставлении: «Процессы или бизнес». Когда одна сторона ставит своё участие и значимость немного выше другой. По принципу «бизнес или процессы — выбирайте». Хотя, на самом деле, а какой ещё должен быть заголовок? Статья полезна тем, кто работает на стыке тесного взаимодействия того, что часто называют бизнесом, и технических или около‑технических команд, для сотрудников разных уровней (от условных джунов до руководителей отделов (Head of sales и прочее)). Также может быть полезна и интересна тем, кто ощущает лёгкий ветерок хаоса в рабочих процессах. Тут нет глубокой аналитики, цифр на основе графиков, графиков на основе исследований учёных британского университета. Только здравый смысл, мои размышления на основе собственного опыта и некоторые рекомендации, что же с этим делать.

https://habr.com/ru/articles/912688/

#процесс #управление_командой #управление_процессами #взаимодействие_с_заказчиком

Не рой аналитику яму: искусство сложных коммуникаций

Привет! Меня зовут Ирина, уже более пяти лет я работаю в сфере бизнес‑ и системного анализа. Сейчас я — системный аналитик Project Ruler. До этого около трех лет занималась внедрением продукта Naumen Contact Center. Поэтому всегда много взаимодействовала с заказчиками, пользователями, разработчиками, тестировщиками и другими участниками процесса. Кажется, все просто: поговорил, собрал требования, передал их в работу. Но на деле коммуникация — один из самых сложных аспектов в работе аналитика. Где‑то не так понял, что‑то вовремя не зафиксировал, не смог отстоять свою позицию — в результате сроки сдвигаются, продукт не попадает в ожидания клиента, а сам аналитик оказывается на грани выгорания. В этой статье я расскажу о шести кейсах из своей практики, в которых именно общение стало ключевым вызовом. Поделюсь ошибками, которые допускала, и инструментами, которые помогли выстроить эффективные коммуникации.

https://habr.com/ru/companies/naumen/articles/895412/

#коммуникации #аналитика #навыки_коммуникации #взаимодействие_с_заказчиком #публичные_выступления #софтскиллы #навыки_аналитика

Как найти общий язык с любым заказчиком: 6 наблюдений из личного опыта

Привет! Меня зовут Аня, я аналитик в Naumen Erudite. За четыре года в компании у меня было несколько проектов внедрения с крупными заказчиками. Не всегда работать на таких проектах легко — нужно уметь находить правильный подход к разным типам заказчиков, чтобы продолжать эффективно взаимодействовать. В статье расскажу о способах коммуникации с разными заказчиками, а также поделюсь советами, как расположить их к себе, научиться отрабатывать отказы, искать компромиссы и шаг за шагом строить хорошие и крепкие отношения на годы вперед.

https://habr.com/ru/companies/naumen/articles/848008/

#коммуникации #типы_заказчиков #общение_с_клиентом #взаимодействие_с_заказчиком #навыки_общения #навыки_аналитика

[Перевод] О неотъемлемой сложности систем

В зависимости от личных предпочтений и потребностей, от уровня абстракций, на котором моделируется мир, а также от места в спектре между идеализмом и цинизмом, можно с полным правом сказать, что работа разработчиков ПО заключается в следующем: написание кода; создание и поддержка качественного ПО; создание и поддержка достаточно хорошего ПО экономически выгодным образом ; управление сложностью; удовлетворение потребностей пользователей; решение задач; удовлетворение потребностей заказчиков; зарабатывание денег для организации-работодателя или для её заказчиков; зарабатывание денег (для себя). Разумеется, этот список далеко не полный. Некоторые из этих задач можно абстрагировать, редуцировать или вывести из других. Некоторые из них фундаментально несовместимы между собой или противоречат друг другу и могут сосуществовать с другими в конфликте. Например: допустим (в определённой мере), что качественное ПО порадует наших пользователей и заработает денег работодателю. Но в то же время нам нужно жертвовать качеством, чтобы оставаться в рамках бюджета, или добавлять функции, которые надоедают пользователям, но генерируют прибыль. Каждая цель проистекает из определённого способа моделирования мира и наших действий. Как и в случае с любой абстракцией, они выполняют свою задачу в подходящем контексте и становятся ложными вне этого контекста; многие проблемы в разработке ПО могут быть объяснены такой искажённой перспективой, о чём я говорил в своём предыдущем посте . В этой статье мы будем считать, что основная задача разработчика ПО — это управление сложностью .

https://habr.com/ru/companies/ruvds/articles/824058/

#ruvds_переводы #сложность_систем #интерфейсы #проектирование_систем #фредерик_брукс #взаимодействие_с_заказчиком