#резюменедели
Новые победы на Tagline Awards🔥
Два наших проекта получили заслуженные награды на конкурсе Tagline Awards✌️
🥇 Золото – за лучший аутстаф-проект: Подели
🥈 Напомню, что и в рейтинге Tagline-2023 мы занимаем второе место среди лучших аутстаф-разработчиков
🥉 Бронза – за лучшее импортозамещающее IT-решение: Linkory
А вот ещё полезности от нас:
Как быстро заключить договор по T&M: 5 инструментов
2 недели до Нового года — не сбавляем обороты 🫶
Новые победы на Tagline Awards🔥
Два наших проекта получили заслуженные награды на конкурсе Tagline Awards✌️
🥇 Золото – за лучший аутстаф-проект: Подели
🥈 Напомню, что и в рейтинге Tagline-2023 мы занимаем второе место среди лучших аутстаф-разработчиков
🥉 Бронза – за лучшее импортозамещающее IT-решение: Linkory
А вот ещё полезности от нас:
Как быстро заключить договор по T&M: 5 инструментов
2 недели до Нового года — не сбавляем обороты 🫶
🔥7👏4🤮1
Media is too big
VIEW IN TELEGRAM
#вопросыбизнеса
Какие языки программирования и технологии будут актуальны в 2024 году
– рассказывает Антон, архитектор
Коротко, за 3,5 минуты – с мини-аналитикой запросов от клиентов 🤗
Какие языки программирования и технологии будут актуальны в 2024 году
– рассказывает Антон, архитектор
Коротко, за 3,5 минуты – с мини-аналитикой запросов от клиентов 🤗
🔥8🤮1💯1
5 софтскилов, актуальных для IT-специалиста в 2024 году
– рассказывает Екатерина, руководитель frontend-отдела
Погружая сотрудников и общаясь с клиентами, мы замечаем, какие навыки наиболее востребованы и влияют на эффективность разработки. Делимся наблюдениями по софтскилам и рассказываем о практических шагах по их развитию в нашей компании.
У кого как ещё настроена система прокачки софтскилов?)
– рассказывает Екатерина, руководитель frontend-отдела
Погружая сотрудников и общаясь с клиентами, мы замечаем, какие навыки наиболее востребованы и влияют на эффективность разработки. Делимся наблюдениями по софтскилам и рассказываем о практических шагах по их развитию в нашей компании.
У кого как ещё настроена система прокачки софтскилов?)
Telegraph
Как развиваем у сотрудников востребованные софтскилы
Всем привет! Меня зовут Екатерина, я руководитель отдела frontend в SimbirSoft. В статье рассказываю о пяти востребованных на проектах комплексных навыках – этот список формировался в ходе работы с нашими сотрудниками и клиентами. Фокус на развитии Для сферы…
👍5🤮1💯1
Media is too big
VIEW IN TELEGRAM
#резюменедели
Порадовались отзыву клиента ☺️
По заказу наших партнёров — компании IconSoft — предоставили своих специалистов для доработки масштабной информационной системы.
✔️Наше сотрудничество — это не только абсолютное погружение специалистов в проекты, обмен экспертизой и качественный результат, но и самое положительное впечатление о совместной работе.
Судя по отзыву технического директора IconSoft Александра Чемоданова, это взаимно💙
Порадовались отзыву клиента ☺️
«Если ребята из SimbirSoft, то в принципе интервью можно не проводить»
IconSoft
По заказу наших партнёров — компании IconSoft — предоставили своих специалистов для доработки масштабной информационной системы.
✔️Наше сотрудничество — это не только абсолютное погружение специалистов в проекты, обмен экспертизой и качественный результат, но и самое положительное впечатление о совместной работе.
Судя по отзыву технического директора IconSoft Александра Чемоданова, это взаимно💙
👏9❤3🤮1💯1
Разработчик не попадает в дедлайны – о чём это может говорить
– рассказывает Павел, руководитель frontend-отдела
Представим ситуацию. Разработчик говорит, что на решение задачи ему понадобится две недели.
А дальше события могут развиваться по-разному, самые критичные варианты выглядят примерно так:
1. Через две недели тимлид пришёл к сотруднику в надежде увидеть результат – оказалось, для решения нужно ещё две недели.
2. Задача выполнена в срок, но после тестирования выявлено большое количество багов. На их устранение нужна минимум неделя.
3. Задача выполнена, но на ревью выяснилось: код не соответствует принятому стайлгайду, UI и компоненты написаны с нуля, хотя их можно было взять из UI-кита. Приведение кода к желаемому виду также займёт одну, а то и две недели.
*
Я больше 10 лет в коммерческой разработке и последние 3 года выполняю роль тимлида на проектах, а также руковожу отделом ~50 разработчиков, которые задействованы на разных продуктах по масштабу и сложности. И могу сказать, что некорректное планирование задачи на самом деле распространено. На какие моменты обратить внимание руководителю, если он столкнулся с подобным?
Возможные причины
🔹 Отсутствие промежуточного контроля. Если слепо верить в корректность оценки сотрудника, можно заметить проблему слишком поздно – когда уже нет возможности скорректировать действия. А «подвести» может и достаточно опытный разработчик: например, он давно не уходил в отпуск – его продуктивность снизилась, а он продолжает оценивать «как раньше».
🔹 Несоответствие уровня решаемых задач и компетенций сотрудника. Здесь всё просто: чем выше уровень задач относительно уровня навыков разработчика, тем выше неопределённость в результате (по времени и качеству).
🔹 Нарушенные коммуникации. Например, сотруднику сообщили, что готовый компонент таблицы уже есть на проекте. Он лежит в репозитории, и его просто нужно взять.
🥁🥁🥁
Репозиториев 12 :) Тимлид в отпуске и не отвечает уже третий день. Другие участники не могут сказать, где лежит этот компонент, а сроки горят. В итоге он пилит свой велосипед, списывает на него 8 часов. На ревью через неделю ему говорят: всё удалить и использовать наше, «ведь мы же говорили взять имеющийся». Это мало того что удорожает разработку, но также в высшей степени демотивирует сотрудника.
Здесь ещё играет роль отсутствие поддержки со стороны команды и плохое погружение сотрудника.
В четверг напомню список must-have практик, которые помогают избегать подобных кейсов 👆
– рассказывает Павел, руководитель frontend-отдела
Представим ситуацию. Разработчик говорит, что на решение задачи ему понадобится две недели.
А дальше события могут развиваться по-разному, самые критичные варианты выглядят примерно так:
1. Через две недели тимлид пришёл к сотруднику в надежде увидеть результат – оказалось, для решения нужно ещё две недели.
2. Задача выполнена в срок, но после тестирования выявлено большое количество багов. На их устранение нужна минимум неделя.
3. Задача выполнена, но на ревью выяснилось: код не соответствует принятому стайлгайду, UI и компоненты написаны с нуля, хотя их можно было взять из UI-кита. Приведение кода к желаемому виду также займёт одну, а то и две недели.
*
Я больше 10 лет в коммерческой разработке и последние 3 года выполняю роль тимлида на проектах, а также руковожу отделом ~50 разработчиков, которые задействованы на разных продуктах по масштабу и сложности. И могу сказать, что некорректное планирование задачи на самом деле распространено. На какие моменты обратить внимание руководителю, если он столкнулся с подобным?
Возможные причины
🔹 Отсутствие промежуточного контроля. Если слепо верить в корректность оценки сотрудника, можно заметить проблему слишком поздно – когда уже нет возможности скорректировать действия. А «подвести» может и достаточно опытный разработчик: например, он давно не уходил в отпуск – его продуктивность снизилась, а он продолжает оценивать «как раньше».
🔹 Несоответствие уровня решаемых задач и компетенций сотрудника. Здесь всё просто: чем выше уровень задач относительно уровня навыков разработчика, тем выше неопределённость в результате (по времени и качеству).
🔹 Нарушенные коммуникации. Например, сотруднику сообщили, что готовый компонент таблицы уже есть на проекте. Он лежит в репозитории, и его просто нужно взять.
🥁🥁🥁
Репозиториев 12 :) Тимлид в отпуске и не отвечает уже третий день. Другие участники не могут сказать, где лежит этот компонент, а сроки горят. В итоге он пилит свой велосипед, списывает на него 8 часов. На ревью через неделю ему говорят: всё удалить и использовать наше, «ведь мы же говорили взять имеющийся». Это мало того что удорожает разработку, но также в высшей степени демотивирует сотрудника.
Здесь ещё играет роль отсутствие поддержки со стороны команды и плохое погружение сотрудника.
В четверг напомню список must-have практик, которые помогают избегать подобных кейсов 👆
👍10😢1🤮1
Включаем разумный контроль
– рассказывает Павел, руководитель frontend-отдела
В предыдущем посте я поделился одной из частых проблем на проектах – непопадание разработчика в дедлайны. Этот и другие негативные кейсы можно избежать, если отследить в самом зачатке и отработать. Основной инструмент здесь – контроль. Моя цель сегодня – ещё раз подсветить его важность и дать must-have практики: от созвонов до процессных моментов.
Это не ноу-хау, но иногда надо возвращаться к базе и проводить экспресс-скрининг. А то бывает уходишь в дебри, работаешь со сложными инструментами, а за ними забываешь о простом и сердитом)
1. Ежедневный статус голосом. Здесь отслеживаем, чем человек занимался в течение дня, и определяем есть ли у него проблемы. Если команда большая или поджимают сроки, статус можно собирать текстом. А возникшие вопросы – обсуждать точечно. Важно (!): один раз в неделю обязательно нужен созвон для обсуждения вопросов голосом.
2. Ежедневные коммиты.
Даже если задача выходит за рамки одного дня и не завершена, необходимо чтобы сотрудник коммитил свою работу за день. В таком случае мы:
▪️ понимаем, что сотрудник пишет код, который соответствует кодстайлу, и движется в правильном направлении;
▪️ снижаем вероятность, что в задаче на 20 часов активная работа начинается в последние 8;
▪️ в случае если разработчик заболел, (/недоступен для связи/ уволился/ у него вышел из строя компьютер/ компьютер украли…) максимальная потеря кода будет не более 8 часов.
3. Декомпозиция задач
Лучше, чтобы подзадача не занимала более 6 часов. Бывают редкие ситуации, когда задачу разбивать мельче чем на 10–15 часов избыточно – тут в игру вступают ежедневные коммиты.
4. Распределение задач
У тимлидов существует подход – давать сотруднику максимально разноплановые задачи, чтобы любой мог заменить любого. Я и сам его приверженец: люблю, чтобы задачи у разработчиков были посильные, но и в то же время достаточно сложные и интересные для них. Так сотрудник постоянно развивается и сохраняет высокий уровень мотивации и лояльности проекту и компании.
К сожалению, в реальной разработке абсолютизировать этот подход не получается. Часто у нас есть на выполнение задачи 8 часов, и мы не можем позволить себе дать её джуну, который будет сидеть с ней в 2–3 раза дольше.
Чем слабее сотрудник, тем более мелкие задачи ему нужно давать: лучше ~ 2–4 часа. Это же правило действует для сотрудников на этапе погружения, чтобы:
▪️ быстрее определить реальный уровень сотрудника,
▪️ быстро заметить, если сотрудник не справляется,
▪️ снизить уровень стресса сотрудника на входе.
5. Актуальная и понятная документация по производственным процессам
В каком состоянии документация на проекте? – Если не описан Flow, то первым делом внимания требуют:
▪️ правила описания задачи при её создании,
▪️ правило перехода задачи из одного статуса в другой, кто становится ответственным для каждого статуса;
▪️ git-flow проекта: правило создания, именования, мёрджа и удаления веток + правило описания коммитов.
На написание инструкции нужно не более четырёх часов + ознакомительный созвон. Чтобы зафиксированные правила выполнялись, первые три недели потребуется пристальное внимание, а когда все привыкнут, усилий нужно гораздо меньше.
Наличие этого документа на 3–5 страницы экономит часы времени на погружении и минимизирует вопросы в процессе работы.
6. Линтер и форматировщик кода*
Пункт со звёздочкой, потому что не всегда получается внедрить линтер. Когда кодовая база уже большая, добавление 3–5 правил может привести к исправлению десятков, а порой и больше сотни файлов. В устоявшейся команде, которая уже привыкла работать без линтера (да, такие существуют) весьма не просто внедрить такие изменения. И часто дело не только в привычке, но и в горящих сроках. Запланировать внедрение и рефакторинг всё-таки надо – на менее активные периоды разработки.
– рассказывает Павел, руководитель frontend-отдела
В предыдущем посте я поделился одной из частых проблем на проектах – непопадание разработчика в дедлайны. Этот и другие негативные кейсы можно избежать, если отследить в самом зачатке и отработать. Основной инструмент здесь – контроль. Моя цель сегодня – ещё раз подсветить его важность и дать must-have практики: от созвонов до процессных моментов.
Это не ноу-хау, но иногда надо возвращаться к базе и проводить экспресс-скрининг. А то бывает уходишь в дебри, работаешь со сложными инструментами, а за ними забываешь о простом и сердитом)
1. Ежедневный статус голосом. Здесь отслеживаем, чем человек занимался в течение дня, и определяем есть ли у него проблемы. Если команда большая или поджимают сроки, статус можно собирать текстом. А возникшие вопросы – обсуждать точечно. Важно (!): один раз в неделю обязательно нужен созвон для обсуждения вопросов голосом.
2. Ежедневные коммиты.
Даже если задача выходит за рамки одного дня и не завершена, необходимо чтобы сотрудник коммитил свою работу за день. В таком случае мы:
▪️ понимаем, что сотрудник пишет код, который соответствует кодстайлу, и движется в правильном направлении;
▪️ снижаем вероятность, что в задаче на 20 часов активная работа начинается в последние 8;
▪️ в случае если разработчик заболел,
3. Декомпозиция задач
Лучше, чтобы подзадача не занимала более 6 часов. Бывают редкие ситуации, когда задачу разбивать мельче чем на 10–15 часов избыточно – тут в игру вступают ежедневные коммиты.
4. Распределение задач
У тимлидов существует подход – давать сотруднику максимально разноплановые задачи, чтобы любой мог заменить любого. Я и сам его приверженец: люблю, чтобы задачи у разработчиков были посильные, но и в то же время достаточно сложные и интересные для них. Так сотрудник постоянно развивается и сохраняет высокий уровень мотивации и лояльности проекту и компании.
К сожалению, в реальной разработке абсолютизировать этот подход не получается. Часто у нас есть на выполнение задачи 8 часов, и мы не можем позволить себе дать её джуну, который будет сидеть с ней в 2–3 раза дольше.
Чем слабее сотрудник, тем более мелкие задачи ему нужно давать: лучше ~ 2–4 часа. Это же правило действует для сотрудников на этапе погружения, чтобы:
▪️ быстрее определить реальный уровень сотрудника,
▪️ быстро заметить, если сотрудник не справляется,
▪️ снизить уровень стресса сотрудника на входе.
5. Актуальная и понятная документация по производственным процессам
В каком состоянии документация на проекте? – Если не описан Flow, то первым делом внимания требуют:
▪️ правила описания задачи при её создании,
▪️ правило перехода задачи из одного статуса в другой, кто становится ответственным для каждого статуса;
▪️ git-flow проекта: правило создания, именования, мёрджа и удаления веток + правило описания коммитов.
На написание инструкции нужно не более четырёх часов + ознакомительный созвон. Чтобы зафиксированные правила выполнялись, первые три недели потребуется пристальное внимание, а когда все привыкнут, усилий нужно гораздо меньше.
Наличие этого документа на 3–5 страницы экономит часы времени на погружении и минимизирует вопросы в процессе работы.
6. Линтер и форматировщик кода*
Пункт со звёздочкой, потому что не всегда получается внедрить линтер. Когда кодовая база уже большая, добавление 3–5 правил может привести к исправлению десятков, а порой и больше сотни файлов. В устоявшейся команде, которая уже привыкла работать без линтера (да, такие существуют) весьма не просто внедрить такие изменения. И часто дело не только в привычке, но и в горящих сроках. Запланировать внедрение и рефакторинг всё-таки надо – на менее активные периоды разработки.
👍5🤮1
☝️ Хороших практик гораздо больше, но я хотел выдать минимальный джентльменский набор, который возможно внедрить в течение одного дня. Изменения не будут болезненным для команды, а эффект заметен через несколько дней. Уже через месяц производительность команды возрастает ощутимо.
А какие ещё простые полезные практики есть в вашем must-have арсенале?)
А какие ещё простые полезные практики есть в вашем must-have арсенале?)
❤🔥3👍2🤮1
#резюменедели
Подводим итоги года 🎆
В этом году прирастали новыми наградами, проектами, людьми, мероприятиями, экспертизой. Ух, столько всего было! Вспоминаем и радуемся 🤩
Спасибо команде:
▪️ тем, кто разрабатывает и тестирует,
▪️ тем, кто пишет,
▪️ тем, кто организовывает корпоративные мероприятия,
▪️ тем, кто считает ресурсы,
▪️ тем, кто прокачивает разработчиков,
▪️ тем, кто общается с клиентами,
▪️ всем и каждому.
SimbirSoft – это большая команда тружеников. Все и всё для того, чтобы делать проекты ещё круче 💙
Подводим итоги года 🎆
В этом году прирастали новыми наградами, проектами, людьми, мероприятиями, экспертизой. Ух, столько всего было! Вспоминаем и радуемся 🤩
Спасибо команде:
▪️ тем, кто разрабатывает и тестирует,
▪️ тем, кто пишет,
▪️ тем, кто организовывает корпоративные мероприятия,
▪️ тем, кто считает ресурсы,
▪️ тем, кто прокачивает разработчиков,
▪️ тем, кто общается с клиентами,
▪️ всем и каждому.
SimbirSoft – это большая команда тружеников. Все и всё для того, чтобы делать проекты ещё круче 💙
❤13🤮1
Media is too big
VIEW IN TELEGRAM
Пожелания бизнесу! 🎅🏼
В 2023 вы точно сделали многое – можно выдыхать, беззаботно улыбаться и по-детски наслаждаться волшебством Нового года 🎄
Мы желаем вам провести праздники в творческой паузе, чтобы порадоваться своим результатам и накопить энергию на важное в 2024!
И традиционно: шлём вам с этим постом миллион сердец! Спасибо, что вы с нами – мы это очень ценим 💙
❤14🤮1
Поставили цели, а что дальше
– рассказывает Дарья, Skill Master
Я адепт дисциплины, а не мотивации. Так что советую забыть о поиске вдохновения и начать выстраивать рутину: привычки будут поддерживать вас независимо от того, вдохновлены вы или нет)
Несколько полезных советов, которые помогают мне:
1. Вести журнал своих прорывов. Помните ли вы, когда достигали чего-то? Обычно наш мозг лучше хранит мысли о незаконченном и несделанном) А вы храните журнал ваших успехов: фиксация результатов помогает увидеть прогресс и не остановиться. Когда у меня что-то не получается, я открываю журнал и вспоминаю: как я шла к своим целям, с какими трудностями сталкивалась и какой итог получила.
2. Создавать подходящую окружающую обстановку. Неважно, работаете вы в офисе или дома – делайте пространство «своим». К примеру, у меня на столе всегда стоит спатифиллум (цветок такой), он помогает мне настраиваться на творческий лад. А админ канала уже месяца два работает под диджей-сеты Cercle – достаточно просто включить, и это уже мгновенно переносит на рабочую волну.
Периодически можно менять обстановку – это приносит оттенки свежести и больше соответствует вашему состоянию «в моменте».
3. Находить единомышленников. Идти с кем-то к цели интереснее и легче. Тут история и о взаимной поддержке, и о возможности обсуждения вопросов, и об обмене полезными находками.
4. Принимать неуспех. Это естественная составляющая развития. Когда я получила права, через неделю я ещё не могла парковаться задом. На нужной мне парковке были мои знакомые, которых я могла попросить о помощи, но мне было стыдно. Я уехала парковаться в другом месте иииии… опоздала на встречу. А можно было бы обратиться к ребятам, а на выходных ещё раз попрактиковаться, когда никуда не надо спешить)
В каждом промахе заложен опыт. Важно осмыслить его, сделать выводы, не опустить руки и продолжить делать то, что нужно. Шаг за шагом, день за днём оттачивая своё мастерство. Ну и полезно уметь относиться к каким-то ситуациям и к себе с юмором, без излишней драматизации 😉
Утренние часы на 40% состоят из привычек. Привычка чистить зубы у нас выработана с самого детства. Тогда что мешает во взрослой жизни добавить в свой режим ещё одну новую привычку?
Когда-то я хотела читать книгу каждый день, но вечно не хватало времени 🙃 Я решила создать привычку: каждое утро после завтрака уделяла 30 минут книге. Через какое-то время день без чтения стал уже неполноценным – я смогла читать в любое удобное для меня время с удовольствием.
Сравню снова с зубами: представим, мы ночуем на природе, зубную щётку забыли, так что утром не смогли почистить зубы. Мы же сделаем это, как только у нас появится возможность! У меня теперь то же самое с книгой. Мне необязательно читать утром – это привычка, которой в течение дня я уже 100% найду время. Так минимальные стартовые действия за долгие годы и собираются в огромные изменения)
– рассказывает Дарья, Skill Master
Я адепт дисциплины, а не мотивации. Так что советую забыть о поиске вдохновения и начать выстраивать рутину: привычки будут поддерживать вас независимо от того, вдохновлены вы или нет)
Несколько полезных советов, которые помогают мне:
1. Вести журнал своих прорывов. Помните ли вы, когда достигали чего-то? Обычно наш мозг лучше хранит мысли о незаконченном и несделанном) А вы храните журнал ваших успехов: фиксация результатов помогает увидеть прогресс и не остановиться. Когда у меня что-то не получается, я открываю журнал и вспоминаю: как я шла к своим целям, с какими трудностями сталкивалась и какой итог получила.
2. Создавать подходящую окружающую обстановку. Неважно, работаете вы в офисе или дома – делайте пространство «своим». К примеру, у меня на столе всегда стоит спатифиллум (цветок такой), он помогает мне настраиваться на творческий лад. А админ канала уже месяца два работает под диджей-сеты Cercle – достаточно просто включить, и это уже мгновенно переносит на рабочую волну.
Периодически можно менять обстановку – это приносит оттенки свежести и больше соответствует вашему состоянию «в моменте».
3. Находить единомышленников. Идти с кем-то к цели интереснее и легче. Тут история и о взаимной поддержке, и о возможности обсуждения вопросов, и об обмене полезными находками.
4. Принимать неуспех. Это естественная составляющая развития. Когда я получила права, через неделю я ещё не могла парковаться задом. На нужной мне парковке были мои знакомые, которых я могла попросить о помощи, но мне было стыдно. Я уехала парковаться в другом месте иииии… опоздала на встречу. А можно было бы обратиться к ребятам, а на выходных ещё раз попрактиковаться, когда никуда не надо спешить)
В каждом промахе заложен опыт. Важно осмыслить его, сделать выводы, не опустить руки и продолжить делать то, что нужно. Шаг за шагом, день за днём оттачивая своё мастерство. Ну и полезно уметь относиться к каким-то ситуациям и к себе с юмором, без излишней драматизации 😉
Утренние часы на 40% состоят из привычек. Привычка чистить зубы у нас выработана с самого детства. Тогда что мешает во взрослой жизни добавить в свой режим ещё одну новую привычку?
Когда-то я хотела читать книгу каждый день, но вечно не хватало времени 🙃 Я решила создать привычку: каждое утро после завтрака уделяла 30 минут книге. Через какое-то время день без чтения стал уже неполноценным – я смогла читать в любое удобное для меня время с удовольствием.
Сравню снова с зубами: представим, мы ночуем на природе, зубную щётку забыли, так что утром не смогли почистить зубы. Мы же сделаем это, как только у нас появится возможность! У меня теперь то же самое с книгой. Мне необязательно читать утром – это привычка, которой в течение дня я уже 100% найду время. Так минимальные стартовые действия за долгие годы и собираются в огромные изменения)
👍9❤2🤮1
This media is not supported in your browser
VIEW IN TELEGRAM
#резюменедели
Вдохновляемся природой 🔊
Вдохновляемся природой 🔊
😁7🤮1
Media is too big
VIEW IN TELEGRAM
#вопросыбизнеса
Зачем участвовать в конференциях
Ещё в ноябре наш ML-специалист Денис выступал на Seymartec Digital 2023 и рассказывал, как повысить вероятность успеха ML-проекта на старте. На самом форуме было много общения, интересных вопросов и докладов от коллег — особенная айтишная атмосфера)
Делимся с вами интервью нашего специалиста для Seymartec ☝️
Зачем участвовать в конференциях
Ещё в ноябре наш ML-специалист Денис выступал на Seymartec Digital 2023 и рассказывал, как повысить вероятность успеха ML-проекта на старте. На самом форуме было много общения, интересных вопросов и докладов от коллег — особенная айтишная атмосфера)
Делимся с вами интервью нашего специалиста для Seymartec ☝️
👍6❤2🤮1
Работа с ожиданиями заказчика: лайфхаки
В своей работе многие компании уже давно сделали ставку на сервис и стараются предугадывать потребности и желания клиентов.
В новой статье мы решили собрать лайфхаки и рекомендации про управление ожиданиями, основанные на личном опыте наших коллег. В посте кратко описываем основные моменты.
✒ Как предотвращать конфликты: управляем «зарядом батарейки» партнёра
Важный и простой на первый взгляд инструмент, про который никогда не стоит забывать во время управления проектом — коммуникации. Если в начале сотрудничества проговорить с заказчиком все его ожидания, а также ясно и открыто обсудить, что и как из этого можно реализовать, то в большинстве случаев это избавит вас от дальнейших недоразумений.
Конечно, клиент представляет интересы целой компании, но он такой же обычный человек со своими проблемами и страхами, целями и желаниями.
В статье мы на примерах рассмотрели, как работать с эмоциональной и рациональной реакциями, а также, как сгладить ситуацию, если «что-то пошло не так»: https://s.simbirsoft.com/bXHt
✒ Как управлять ожиданиями: лайфхаки и работающие способы
Есть несколько работающих способов, применяя которые, руководитель проекта вместе с командой может «вытащить» проект из негатива или хаоса. В статье мы описали их полностью, здесь обозначим кратко:
1) Создайте общий документ с требованиями.
2) Постоянно общайтесь с заказчиком.
3) Делите проект на более короткие спринты и циклы разработки.
4) Создайте процесс управления изменениями.
Мы надеемся, применение этих инструментов на ваших проектах поможет улучшить управление ожиданиями заказчика и минимизировать возможные негативные последствия недопониманий.
Если у вас есть дополнения или свои рекомендации, будем рады их увидеть в комментариях.
В своей работе многие компании уже давно сделали ставку на сервис и стараются предугадывать потребности и желания клиентов.
В новой статье мы решили собрать лайфхаки и рекомендации про управление ожиданиями, основанные на личном опыте наших коллег. В посте кратко описываем основные моменты.
✒ Как предотвращать конфликты: управляем «зарядом батарейки» партнёра
Важный и простой на первый взгляд инструмент, про который никогда не стоит забывать во время управления проектом — коммуникации. Если в начале сотрудничества проговорить с заказчиком все его ожидания, а также ясно и открыто обсудить, что и как из этого можно реализовать, то в большинстве случаев это избавит вас от дальнейших недоразумений.
Конечно, клиент представляет интересы целой компании, но он такой же обычный человек со своими проблемами и страхами, целями и желаниями.
В статье мы на примерах рассмотрели, как работать с эмоциональной и рациональной реакциями, а также, как сгладить ситуацию, если «что-то пошло не так»: https://s.simbirsoft.com/bXHt
✒ Как управлять ожиданиями: лайфхаки и работающие способы
Есть несколько работающих способов, применяя которые, руководитель проекта вместе с командой может «вытащить» проект из негатива или хаоса. В статье мы описали их полностью, здесь обозначим кратко:
1) Создайте общий документ с требованиями.
2) Постоянно общайтесь с заказчиком.
3) Делите проект на более короткие спринты и циклы разработки.
4) Создайте процесс управления изменениями.
Мы надеемся, применение этих инструментов на ваших проектах поможет улучшить управление ожиданиями заказчика и минимизировать возможные негативные последствия недопониманий.
Если у вас есть дополнения или свои рекомендации, будем рады их увидеть в комментариях.
РБК Компании
Работа с ожиданиями заказчика: лайфхаки от SimbirSoft | РБК Компании
SimbirSoft (ООО «СимбирСофт»): Умение управлять ожиданиями заказчиков в условиях нестабильности и постоянных перемен становится важнее, чем когда-либо ранее. Как это делать эффективно
👍2❤🔥1🤮1
Какие вопросы к владельцу продукта помогают снизить неопределённость
– рассказывает Екатерина, PM
Когда руководители проектов получают от клиента краткое описание будущей системы, настаёт время выяснить детали. Для этого у меня есть любимая техника. На мой взгляд, она максимально устраняет неопределённость – там затронуты самые основные вопросы, которые помогут клиенту и команде в будущей разработке.
Рисуем квадрат и распределяем уточняющие вопросы по четырем блокам:
▪️ Пространство: где?
▪️ Время: когда?
▪️ Ресурсы: что, как, сколько?
▪️ Отношения: кто?
Под постом прикрепила пример для типового приложения (вопросов будет больше, если решение специфичное).
Я выделила для себя маркеры успешной первой встречи:
▪️ заданы заранее заготовленные и возникшие в ходе беседы вопросы по всем четырём пунктам,
▪️ получены ответы на половину и более заданных вопросов,
▪️ заказчик задавал встречные вопросы.
– рассказывает Екатерина, PM
Когда руководители проектов получают от клиента краткое описание будущей системы, настаёт время выяснить детали. Для этого у меня есть любимая техника. На мой взгляд, она максимально устраняет неопределённость – там затронуты самые основные вопросы, которые помогут клиенту и команде в будущей разработке.
Рисуем квадрат и распределяем уточняющие вопросы по четырем блокам:
▪️ Пространство: где?
▪️ Время: когда?
▪️ Ресурсы: что, как, сколько?
▪️ Отношения: кто?
Под постом прикрепила пример для типового приложения (вопросов будет больше, если решение специфичное).
Я выделила для себя маркеры успешной первой встречи:
▪️ заданы заранее заготовленные и возникшие в ходе беседы вопросы по всем четырём пунктам,
▪️ получены ответы на половину и более заданных вопросов,
▪️ заказчик задавал встречные вопросы.
🔥7👍4🤮1