Что делать, если клиент пришел с проектом перед Новым годом
– рассказывает Ринат Шамшутдинов, руководитель mobile
Контекст:
Дело было несколько лет назад. Под самый конец года к нам обратился клиент – 21 января он планировал показать MVP-версию мобильного приложения инвесторам. В конце декабря он понял, что предыдущий подрядчик, кажется, не успевает. И пришёл к нам с кодом для оценки – сможем сделать или нет.
Я тогда был разработчиком. Вот проверяю полученный код, проверяю, проверяю и понимаю – интеграции никакой нет, бизнес-логика не заложена. У нас есть вёрстка :) Словно предыдущий подрядчик показывал клиенту «прогресс», на самом деле демонстрируя лишь вёрстку. Получается, экран как бы есть – кнопки нажимаются, но «под капотом» ничего не происходит 🥲
Ну что? Погнали!)
Итак, при каких условиях на такой проект можно соглашаться
1. Заказчик принимает риск. В таких условиях непонятно, сколько точно по времени займёт доработка. Вёрстка-то она статичная, а вот прикрутить динамические компоненты, логику при подключении к серверу – это совсем другое дело. То есть мы сказали, что мы согласны попробовать и постараемся успеть. НО подготовили заказчика к тому, что может возникнуть форс-мажор. Он доверился нам.
1.2. Заказчик не требует оценку по фиксе.
2. У вас есть PM и достаточно специалистов, которые готовы вписаться в такую авантюру. На тот момент PM’а с нами не оказалось, но в лодке было:
▪️ трое разботчиков: накидали архитектуру (решили делать с нуля, так было проще), поделили между собой бизнес-фичи, оттолкнулись от основных сценариев для презентации 21 января;
▪️ руководитель mobile: поддерживал нас в процессе и сделал интеграцию с AWS для загрузки файлов;
▪️ заказчик: докручивал backend на Битриксе.
Мы, разработчики, восприняли всё это как челлендж, который интересно выполнить. С 3 января мы работали full-time 5/2. Через две недели готова была версия для тестирования. Если команда не готова к такому, откажитесь от проекта.
3. Уровень разработчиков позволяет им работать по Scrum. Даже если они не задумываются об этом. Мы каждый день обновляли статусы фич, следили за диаграммой Ганта, чтобы точно успеть протестировать и исправить баги. Нам дали задачу – сделать мобильное приложение. Мы пошли и сделали – составили список задач, спланировали их выполнение и распределили. В общем, чистый Scrum) Взяли ответственность на себя и самоорганизовались)
4. Интересно дальнейшее сотрудничество. Хотя мы честно симпатизировали заказчику, по-человечески хотели ему помочь, но всё-таки альтруизм в рабочих отношениях может привести к ненужному никому выгоранию. Важен деловой подход и оценка перспектив. В нашем случае ситуация была win-win: мы не сомневались, что сотрудничество продолжится.
5. С самого начала с заказчиком – контакт. Невозможно одолеть такой проект, если вы не будете единым механизмом. Тут мы разговаривали на одном языке, нам не нужно было объяснять приоритет фич для MVP, почему мы начали с нуля и т.д. Это сохраняло силы и время.
P.S. Презентация прошла хорошо. После мы в спокойном темпе доработали проект и успешно его завершили🤘
– рассказывает Ринат Шамшутдинов, руководитель mobile
Контекст:
Дело было несколько лет назад. Под самый конец года к нам обратился клиент – 21 января он планировал показать MVP-версию мобильного приложения инвесторам. В конце декабря он понял, что предыдущий подрядчик, кажется, не успевает. И пришёл к нам с кодом для оценки – сможем сделать или нет.
Вёрстка была прекрасная,
Всё остальное былоужасноепустое.
(Если бы Сапгир был айтишником)
Я тогда был разработчиком. Вот проверяю полученный код, проверяю, проверяю и понимаю – интеграции никакой нет, бизнес-логика не заложена. У нас есть вёрстка :) Словно предыдущий подрядчик показывал клиенту «прогресс», на самом деле демонстрируя лишь вёрстку. Получается, экран как бы есть – кнопки нажимаются, но «под капотом» ничего не происходит 🥲
Ну что? Погнали!)
Итак, при каких условиях на такой проект можно соглашаться
1. Заказчик принимает риск. В таких условиях непонятно, сколько точно по времени займёт доработка. Вёрстка-то она статичная, а вот прикрутить динамические компоненты, логику при подключении к серверу – это совсем другое дело. То есть мы сказали, что мы согласны попробовать и постараемся успеть. НО подготовили заказчика к тому, что может возникнуть форс-мажор. Он доверился нам.
1.2. Заказчик не требует оценку по фиксе.
2. У вас есть PM и достаточно специалистов, которые готовы вписаться в такую авантюру. На тот момент PM’а с нами не оказалось, но в лодке было:
▪️ трое разботчиков: накидали архитектуру (решили делать с нуля, так было проще), поделили между собой бизнес-фичи, оттолкнулись от основных сценариев для презентации 21 января;
▪️ руководитель mobile: поддерживал нас в процессе и сделал интеграцию с AWS для загрузки файлов;
▪️ заказчик: докручивал backend на Битриксе.
Мы, разработчики, восприняли всё это как челлендж, который интересно выполнить. С 3 января мы работали full-time 5/2. Через две недели готова была версия для тестирования. Если команда не готова к такому, откажитесь от проекта.
3. Уровень разработчиков позволяет им работать по Scrum. Даже если они не задумываются об этом. Мы каждый день обновляли статусы фич, следили за диаграммой Ганта, чтобы точно успеть протестировать и исправить баги. Нам дали задачу – сделать мобильное приложение. Мы пошли и сделали – составили список задач, спланировали их выполнение и распределили. В общем, чистый Scrum) Взяли ответственность на себя и самоорганизовались)
4. Интересно дальнейшее сотрудничество. Хотя мы честно симпатизировали заказчику, по-человечески хотели ему помочь, но всё-таки альтруизм в рабочих отношениях может привести к ненужному никому выгоранию. Важен деловой подход и оценка перспектив. В нашем случае ситуация была win-win: мы не сомневались, что сотрудничество продолжится.
5. С самого начала с заказчиком – контакт. Невозможно одолеть такой проект, если вы не будете единым механизмом. Тут мы разговаривали на одном языке, нам не нужно было объяснять приоритет фич для MVP, почему мы начали с нуля и т.д. Это сохраняло силы и время.
P.S. Презентация прошла хорошо. После мы в спокойном темпе доработали проект и успешно его завершили🤘
👍6🔥3🤮1
#резюменедели
Новые победы на 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