Синергия аналитика и разработчика

19.12.23

Команда - Коммуникации

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

 

Меня зовут Екатерина Статкевич, я руководитель отдела разработки в крупной ИТ-компании. Мы занимаемся разработкой финтех-сервисов, их сопровождением и поддержкой.

Опыт работы у меня более 18 лет – я прошла путь от разработчика до руководителя.

Обладаю опытом работы с людьми и формирования команд – на текущий момент у меня в команде по направлению 1С 12 разработчиков и 5 аналитиков.

 

 

Поговорим на актуальную тему синергии аналитика и разработчика. Я расскажу о том, что:

  • Без аналитика обойтись можно, но без аналитики – нельзя. Эта тема – актуальная: не новая, но мы до сих пор это обсуждаем. Самое интересное, что до сих пор встречаются заказчики, у которых есть вопрос: «Нужен ли аналитик на проекте, или достаточно просто найти #Тыжпрограммиста – набрать кодеров, и они выпустят больше задач?»

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

  • И покажу немного фактов – как взаимодействие аналитика и разработчика помогло нам вывести систему из технического долга. Мы были настолько «на дне», что снизу постучали. Но включение аналитика на проект дало нам положительный эффект.

 

 

Аналитики бывают разные, но я в своем докладе буду делать акцент именно на бизнес-анализе и на системном анализе.

  • Бизнес-аналитик – это человек, ответственный за сбор требований. Он собирает функциональные требования с заказчика, согласует эти требования и напрямую работает с бизнесом. Самый главный вопрос, который ему нужно выяснить: «Для чего пользователям нужна наша новая система или улучшения в этой системе».

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

 

Без Аналитика можно. Без Аналитики – нельзя

 

 

Отсутствие в команде аналитика как отдельной роли означает, что эти работы точно будет делать кто-то другой.

  • Например, бизнес-требования может собрать и проработать с заказчиком менеджер проектов, тимлид или разработчик.

  • То же самое с системным анализом:

    • Системные требования может собрать и описать тимлид.

    • Поставить задачу разработчику тоже может тимлид.

    • А еще разработчик может все это сделать сам.

На слайде – картинка из крутого доклада Славы Панкратова про человека-снежинку. Он заканчивается словами: «И тут тебя не стало. Ты стал человеком-снежинкой». Когда один человек на проекте выполняет несколько ролей, это приводит к тому, что страдают сроки и качество. Каждый на проекте должен заниматься своим делом.

 

Жизненный цикл бизнес-задачи/проекта

 

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

 

 

На слайде – жизненный цикл нашей бизнес-задачи от инициации до приемки заказчиком:

  • Зеленым цветом я здесь выделила блоки этапов, где присутствует бизнес-анализ.

  • Синим цветом – блоки, где присутствует системный анализ.

  • Блоки, которые в блок-схеме не выделены цветом – это чисто бизнесовые блоки, когда бизнес общается только между собой.

  • Также цветом не выделены чисто статусные блоки, такие как «Ожидание разработки» или «Формирование релиза». Например, на этапе «Ожидание разработки» задача ожидает, когда у нас появятся ресурсы.

Если кратко по блокам:

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

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

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

Далее у нас есть этап экспресс-оценки – мы смотрим те задачи, которые к нам поступили.

У нас очень большой стек технологий – в нашем хозяйстве порядка 30 систем. На экспресс-оценке мы уже архитектурным комитетом анализируем, какие системы у нас участвуют в этой бизнес-идее, и даём верхнеуровневую оценку, сколько нам нужно времени по каждой системе, чтобы это реализовать.

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

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

Было же у вас такое, когда вам заказчик даёт задачу, а там: «Сделай, чтобы было хорошо», и всё? В этот момент мы не можем дать оценку – ок, мы можем делать хорошо, а где, на какой системе?

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

У нас задачи делятся на два типа:

  • есть большие проекты – те, которые исполняются больше 14 рабочих дней и касаются более двух систем;

  • и есть мелкие BAU-задачи, как мы их называем – те, которые касаются одной системы или взаимодействия двух систем и требуют меньше 14 рабочих дней на исполнение.

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

А если задачи большие, мы их отправляем на этап B4B – он на схеме между инициацией и экспресс-оценкой. B4B – это бизнес для бизнеса, где встречаются только бизнес-заказчики. Здесь обсуждаются важные проекты, которые нужно реализовать для запуска нового продукта. На этих этапах, естественно, нет ни системного, ни бизнес-аналитика.

Дальше у нас идет этап бизнес-анализа, куда подключается бизнес-аналитик – это можно понять уже из названия. На этапе бизнес-анализа мы описываем, собираем функциональные требования, критерии приемки и уже более детально даем описание к той функциональности, которую нам нужно реализовать.

Этап согласования требований – здесь уже тоже бизнес-аналитики, они передают задачу на этап согласования требований. Здесь тоже бизнес работает только между собой. Если задача со смежными подразделениями – например, она затрагивает производство и склад, и нужно, чтобы одно не поломало другое. Либо если нужно получить согласование от этих подразделений – в этом случае мы отправляем на этап согласования требований.

Дальше у нас проходит этап архитектуры. На этапе архитектуры присутствуют системные аналитики – архитектор, системный аналитик и тимлиды прописывают архитектуру нашей задачи.

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

Дальше цикл не уместился и перешел на ту сторону – идет этап ожидания разработки. Когда нет ресурсов, и задача ждет.

И потом у нас идет этап разработки. Здесь работают разработчики в сотрудничестве с системными аналитиками. Далее будет слайд, я покажу, как детализируется процесс разработки, но на этапе разработки мы тоже работаем с системными аналитиками.

Дальше, у нас идет этап тестирования. Этап тестирования – это отдельный тестовый контур. «Тестирование», «UAT», «Формирование релиза» и «Готово к релизу» – это задачи наших тестировщиков. Но на этапе тестирования мы привлекаем бизнес-аналитика, чтобы проанализировать по критериям приемки, правильно ли мы сделали. И привлекаем системного аналитика, который взаимодействует с отделом тестирования и показывает, как он ставил задачу разработчику. Далее, он принимает задачу от разработчика и проводит преддемо нашему отделу тестирования.

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

 

 

Введение этого регламента помогло нашему бизнесу закрывать задачи более эффективно. На слайде – немного цифр за 2022 год.

  • Маленьких BAU-задач мы за 2022 год реализовали порядка 436;

  • Крупных задач-проектов – мы их называем CR – у нас за 2022 был реализован 31 проект.

А с помощью такого регламента взаимодействия мы уже с января по апрель сделали:

  • более 260 маленьких задач;

  • и 30 проектов.

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

Прежде чем рассказать про взаимодействие аналитика и разработчика, хочу резюмировать про бизнес-анализ и системный анализ:

  • если задачи малые, разделение ролей на бизнес-анализ и системный анализ нецелесообразно;

  • а на больших проектах, в больших масштабных работах это уже будет определенно оправдано.

 

Как организовать совместную работу

 

 

Часто между аналитиком и разработчиком встречается сопротивление к совместной работе.

  • Разработчик не хочет работать в команде с аналитиком, объясняя это тем, что: «Я же быстрее все сам сделаю. Там все понятно. Я сам. Не лезь, я лучше знаю».

  • А аналитик, с другой стороны, не хочет погружаться в техническую задачу: «Ты же знаешь, как должно быть. Сделай, чтобы работало, и этого достаточно».

Тут проблема, чаще всего, не в людях – проблема в организации командного взаимодействия и в организации процесса.

Не всегда люди понимают, где заканчивается процесс анализа, и где начинается процесс разработки.

 

 

На слайде – детализация кусочка жизненного цикла бизнес-задачи, который отвечает за взаимодействие разработчика и аналитика.

Здесь у нас нет бизнес-анализа, работает только системный анализ – это касается случая, когда эти роли разделены.

  • Схема жизненного цикла начинается с момента, когда мы детализировали бизнес-идею до более мелких задач, которые будут попадать в бэклог разработчику, и передали задачу в разработку. В момент, когда задача поступает в разработку, она сначала ставится на обсуждение – этап «На обсуждении».

  • Потом задача попадает к разработчику в бэклог – он ее помещает на доску по проекту, на этап «Нужно сделать».

  • И далее переходит на этап «В работе» – разработчик берет ее в работу. Причем он берет ее в работу вместе с системным аналитиком, потому что системный аналитик ставил задачу. Даже если они взаимодействуют друг с другом просто через описание задачи, они работают вместе в течение всего того времени, пока разработчик разрабатывает задачу.

  • Далее задача проходит этап «Код-ревью».

  • Попадает на этап «Ожидание сборки», когда мы выкладываем наш мини-релиз на тестирование.

  • И дальше есть этап «Внутреннее тестирование». На этом этапе системный аналитик, который ставил задачу разработчику, проверяет, как разработчик ее выполнил – в идеальной картине мира системный аналитик проверяет свою же постановку задачи.

  • Дальше задача переходит на этап «Разработка завершена».

  • И попадает на этап «Тестирование ОТ» – на этом этапе тестирования системный аналитик взаимодействует с отделом тестирования. Мы сделали задачу, показываем нашему отделу QA преддемо, рассказываем о функциональности, которая изменилась, и объясняем, какие у нее критерии приемки. Пока задача тестируется – день-два-три-шесть, в зависимости от объемов – у отдела тестирования возникают вопросы. Мы ограждаем от этих вопросов разработчика, чтобы он у нас только кодил – с ним взаимодействует только системный аналитик.

Вот такой у нас процесс, так организована командная работа разработчика и системного аналитика.

 

Отсутствие готовности к совместной работе: разработчик не хочет работать в команде с аналитиком, а аналитик не хочет погружаться в техническую сторону реализации задачи

 

 

Не всегда бывает все гладко – в командах случаются проблемы. Расскажу свои советы о том, как эти проблемы обойти.

Но перед этим хочу обратить ваше внимание на постулат Agile, который гласит, что бизнесу нужно обязательно взаимодействовать с ИТ. Я сейчас побуду немного бунтарем и скажу: с ИТ – да, бизнесу действительно нужно взаимодействовать, но с разработчиками – нет, не нужно. Мы полностью оградили разработчиков от бизнеса.

Бывало же у вас такое, что нужно изменить бизнес-требования к задаче? Например, у задачи несколько заказчиков – Бухгалтерия, Отдел кадров и другие подразделения. Поставили у совещания тайминг 20-30 минут – за 20-30 минут все обсудили, договорились и ушли. Верите? Обычно обсуждения по изменению либо постановке требований – это поиск правды. Эти обсуждения затягиваются. И мы у себя в компании ограждаем разработчиков от этих обсуждений. У нас роль взаимодействия с бизнесом берет на себя системный либо бизнес-аналитик. Мы знаем систему не хуже разработчиков и выясняем все требования сами. А разработчики у нас только кодят.

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

Одна из проблем – это взаимное недоверие. Разработчик не верит, что аналитик поставил задачу корректно: «Что он написал вообще, задача же не об этом?..». А аналитик не верит, что разработчик разберется в логике системы: «Что он там сейчас накодит…»

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

  • Все ли тебя устраивает в том, как я описал интеграционные контракты?

  • Все ли понятно в требованиях?

Важно получать эту обратную связь и корректировать свою дальнейшую работу.

 

 

Еще один порок у команды – это уход от конфликтов, когда проще не спорить: «Он считает, что так надо, пусть будет так. У меня есть свое мнение, но я лучше промолчу».

Люди не вступают в дискуссию, они не обсуждают возможные проблемы. Но самые дорогие ошибки – это ошибки проектирования. У системного аналитика – это постановка требований. У разработчика – это кодирование. Чем быстрее найти ошибку на этапе проектирования, тем дешевле будет ее исправить.

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

Как с этим бороться?

  • Во-первых, нужно проводить совместные планерки, дейли. Аналитикам с разработчиками нужно каждый день обсуждать задачи в диалоге: «Что ты сделал вчера? Что ты будешь делать сегодня? Чем я тебе могу помочь? Давай посмотрим вместе – что получается, а что не получается».

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

  • И для профилактики возможных конфликтов и проблем нужно представлять интересы разработчика перед бизнесом. Допустим, запрашивают одну функциональность, а разработчику с технической стороны виднее – он понимает, что это будет работать неоптимально, лучше сделать по-другому. Здесь нужно вступать в диалог с бизнесом и предлагать альтернативные идеи для реализации их потребностей. Бизнес же не всегда знает, как это предусмотрено в системе. Ты приходишь к ним и рассказываешь, а они тебе говорят: «А что, так можно было? Да, давайте сделаем так». Здесь тоже важен диалог, и системный аналитик должен представлять интересы разработчика перед бизнесом – предлагать альтернативные идеи реализации.

 

 

Еще есть такой порок, как необязательность – это когда мы не можем поддержать принятые решения. Мы решаем этот вопрос через подведение итогов после каждой встречи.

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

  • Если мы встретились, чтобы провести мозговой штурм для проектирования архитектуры – нужно зафиксировать, о чем мы договорились. И в конце обязательно спросить – правильно ли мы все понимаем друг друга? Нужно подвести итоги и проговорить все принятые решения, чтобы убедиться, что мы их понимаем в одном контексте. Лучше договориться о решениях заранее, перед тем, как мы начнем их реализовывать на практике.

  • Нужно проанализировать худший сценарий развития событий. Порассуждать на тему – вдруг что-то пойдет не так. Например, сейчас у нас в регистре десять записей, и все будет работать быстро. А как это будет работать, если их завтра в регистре будет тысяча записей и с каждым днем прирост будет увеличиваться? Будет ли это работать оптимально или нет?

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

    • Что нужно сделать в системе со стороны разработчика – со стороны проверки кода и каких-то настроек;

    • Что нужно сделать в системе со стороны аналитика – настроить печатные формы, если это Документооборот, перенести карты бизнес-процессов, если это CRM и так далее. То, что мы делаем уже на релизе.

 

 

Нетребовательность к другим – еще один интересный порок, когда мы не требуем качественного результата от других членов команды.

В этом тоже помогает ряд профилактических мер:

  • Разработка стандартов постановки задачи – например, для описания контрактов на интеграцию.

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

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

 

 

Еще один порок – безразличие к общему результату. Когда «сделал, и ладно».

Здесь работают следующие профилактические меры:

  • Контроль реализованной функциональности после выпуска релиза. Определите для задачи, сколько времени нужно мониторить результат, чтобы убедиться, что все точно работает. Например, для доработки какого-то регламентированного отчета можно определить период мониторинга – квартал. Отчетность сдали – значит, все работает, уже можно фокус внимания снизить.

  • Взаимодействие аналитика с отделом тестирования. Если будет фокус на общий результат, системный аналитик будет более заинтересован в том, чтобы задача выпустилась правильно. Чем более качественно ее сделал разработчик, тем меньше дефектов – тем меньше системный аналитик взаимодействует с отделом тестирования.

 

Реальный кейс, как включение Аналитика на проект позволило нам вывести систему из кризиса и закрыть технический долг

 

 

Немного фактов.

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

В качестве бэкенда для работы ПО использовались конфигурации Бухгалтерия предприятия, БИТ.Финанс и БИТ.Центр управления лизингом.

В июне 2022 года мы выпустили MVP. Пока мы выпускали MVP, у нас на проекте присутствовал системный аналитик, но потом мы системного аналитика отдали на другой проект, а на проекте остались тимлид и разработчик.

Что стало происходить:

  • в июне системный аналитик перешел на другой проект;

  • в июле мы начали захлебываться в дефектах – на графике синим цветом показаны открытые задачи, а зеленым – дефекты;

  • в августе, пока память свежа, мы эти дефекты закрывали, но у нас продолжали лететь новые дефекты.

С чем мы столкнулись:

  • Полное возмущение клиентов.

  • Нам не доверяет бизнес.

  • У нас ежедневные совещания по стабилизации, на которые бизнес приходит и говорит: «Что там у вас сегодня?» Потому что бизнес тоже устал – это Бухгалтерия предприятия, там отчетность, с этим тоже связаны свои опасения. На эти ежедневные совещание мы ходим с опущенной головой.

  • Ситуация была критическая: наше установленное ПО в случае просрочки по оплате выдавало на экран предупреждение «оплатите, пожалуйста». И на третий день телефон становился кирпичом. Даже если заплатить, телефон уже кирпич – по нему даже позвонить не получится. И вернуть его из состояния кирпича не получится, потому что у нас дефекты.

Мы ловим дикое возмущение наших клиентов: нам угрожают судами, у нас трясутся коленки-руки, мы судорожно тушим пожары. Задач много, это только MVP, нужно еще и развиваться, у нас встал вопрос: кого привлекать – разработчика или аналитика? И мы сделали ставку на аналитика.

  • Аналитик погрузился на проект в августе.

  • И уже в сентябре прекратились ежедневные совещания по стабилизации – они стали еженедельными.

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

На текущий момент система живет с минимальным вмешательством с нашей стороны.

 

 

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

Если у аналитика с разработчиком срабатывает эта синергия, у бизнеса растет доверие к нам, потому что мы выпускаем ровно то, что от нас хотели. Это в краткосрочной перспективе.

А в долгосрочной перспективе это еще дает возможность побороть саботаж при внедрении изменений.

И последнее: я хочу высказать благодарность моему первому аналитику Анастасии Евгеньевне.

18 лет назад я была таким же амбициозным #Тыжпрограммистом, который очень много знал о кодировании и ничего не знал об аналитике, и не считал это важным.

Спасибо тебе большое, Анастасия Евгеньевна, за то, что ты меня научила. С тех пор я уверена в том, что без аналитика на проекте нельзя.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".

См. также

Сопровождение Внедрение изменений Коммуникации Обучение и наставничество Бесплатно (free)

Давайте честно – пользователи не любят перемены. Особенно когда это касается учетных систем. В этих условиях для сохранения своей и пользовательской нервной системы важно выстроить грамотную линию поддержки: не только технической, но и психологической. Расскажем о попытках сгладить всесторонней поддержкой неизбежное раздражение пользователей в период перехода «Самоката» с Directum RX на 1С:ДО.

03.12.2024    190    0    user1852187    0    

2

Коммуникации Лидерство Компетенции и навыки РП Бесплатно (free)

Любой управленец периодически сталкивается с ситуациями, в которых необходимо принять волевое решение, но непонятно, с какого конца хвататься. Эдакий сферический конь висит перед носом и скалит зубы при попытке его потрогать. Страшно, но делать с этим что-то надо… Расскажем об универсальном алгоритме разбора ситуации и составлении плана действий по управленческим кейсам.

11.11.2024    370    6    dklimchuk    2    

3

Компетенции и навыки РП Коммуникации Бесплатно (free)

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

06.11.2024    724    0    Kukabarra    2    

7

Коммуникации Фасилитация Лидерство Бесплатно (free)

Шаблонное мышление у руководителя - плохо или хорошо? Как его избежать с помощью методики "6 шляп" мышления.

02.09.2024    832    0    ashtey    0    

2

Коммуникации Продуктовый подход Бесплатно (free)

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

25.07.2024    537    0    user1142961    0    

3

Коммуникации Личная эффективность Обучение и наставничество Бесплатно (free)

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

23.07.2024    1880    0    SerjoginaMaria    6    

13

Коммуникации ИТ-компания Бесплатно (free)

Многие руководители считают, что сто человек работают в сто раз эффективнее, чем один. Однако масштабирование – нелинейный процесс. Производительность большой команды не всегда равна сумме производительностей ее членов. Как сделать так, чтобы члены команды усиливали друг друга, а не тормозили? Компания ИСВС проходила этот путь и знает ответ!

12.04.2024    4779    0    vasilnikol    19    

30

Коммуникации Бесплатно (free)

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

27.02.2024    2180    0    user1561517    3    

16
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user596529_a-ivashenko60 28.12.23 16:10 Сейчас в теме
"... как включение Аналитика на проект позволило нам вывести систему из кризиса ...".
После прочтения дальнейшего текста переведем его на "русский язык". Получим. Некая доблестная фирма начала работу над большим проектом. Выполнила определенную работу. Потом "зажлобилась" и уволила одного сотрудника (аналитика), решила так сказать сэкономить. И срубить "бабло" задешево.
Но ... не срослось. После макания заказчиком нашей доблестной фирмы мордой в дерьмо пришлось опять раскошеливаться на сотрудника (то что в данном случае им оказался "аналитик" чистое совпадение, это мог быть и другой находящийся в теме сотрудник). И проект был сделан.
Мораль сей басни: не жлобись!
Оставьте свое сообщение