Привет!

Здесь мы делимся подходами и практиками в менеджменте #management и разработке #development. Опытом компании, tips and tricks.

Послушать наши голоса можно в подкасте SmartHead Space 🎙

Стать частью команды SmartHead 👉 https://smarthead.ru/#vacancies

По организационным вопросам — @doctorsolberg

#development

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

Developer Experience (DX) — это частный случай UX, когда в качестве пользователя выступает разработчик, а в качестве продукта — язык программирования, фреймворк, технология, сервис или любой другой инструмент.

Продукт с хорошим DX ведёт разработчика, даёт возможность сфокусироваться на решении задачи, а не возиться в конфигурации инструмента. Хороший DX повышает удобство и скорость разработки, даёт уверенность в отсутствии ошибок и комфорт в работе.

#development

Что отличает инструмент с хорошим DX?
— Быстрый старт. Он не требует много времени в начале, а погружает по мере необходимости.
— Отличная документация. Понятный quick start, хорошая структура, полнота и актуальность.
— Хорошая коммуникация с пользователем через интерфейсы взаимодействия, в том числе cli и API.
— Адекватные параметры по умолчанию. Инструмент не требует большой конфигурации, возможно следует принципу Convention over Configuration. Он не заставляет разработчика принимать решения там, где это не требуется. А там, где требуется изменить поведение по умолчанию, даёт возможность это сделать.
— Следование стандартам индустрии и идиомам платформы. Стиль кода или наименование методов в API не вызывают удивления.
— Open source и использование возможностей сообщества разработчиков.

Хорошим DX следует не только пользоваться, но и производить самим. При разработке стоит задумываться о DX и разработчиках, которые пользуются нашим кодом.

#management

Мы часто слышим от руководителей и собственников бизнеса тезисы вроде «Без цели нет развития. Четко пойми чего ты хочешь, поставь цель, определи шаги ее достижения и вперед!» У них много производных:

— Нужно улучшить результаты отдела? Установи планы и метрики для подчиненных, задай цели им!
— Нужны продажи? Сделай план продаж и пусть люди работают на его достижение!
— Не можешь четко сказать, что ты хочешь и поставить цель? Так бизнес не делается, ты не прав. Это все игры и самореализация, а не бизнес.

Давайте разберемся и поставим эти утверждения под сомнение.

#management

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

— Цели не всегда возможно поставить качественно, например, по SMART. Во многих сферах бизнеса и ситуациях мы не настолько хорошо владеем контекстом и управляем влиянием факторов, чтобы ставить аргументированные и достижимые цели.
— Вы можете проработать их до мельчайших деталей. Но качественная проработка и декомпозиция цели до атомарного уровня занимает огромное количество времени.
— Очень часто самым важным компонентом цели ставят срок. Но иногда другие факторы гораздо важнее. Например, способ ее достижения.
— Поставить цель мало. Ее нужно сбалансировать с другими процессами, чтобы не допустить «провалов» по другим фронтам, которые в данную цель не попали. Банальный пример — поставить амбициозные цели по продажам услуг и обнаружить, что при выполненной цели качество услуг сильно упало, а сотрудники производственных отделов обновили резюме на HH.

Даже после постановки цели могут принести много проблем. Например, с любой нетривиальной целью в нагрузку идет рюкзак стресса. Зафиксировав четкую цель, сложно отказаться от следования к ней, даже если она уже потеряла актуальность. Особенно если над одной целью работает группа людей. Часто встречается когнитивное искажение невозвратных потерь. Это ведет к тому, что вы не получаете удовлетворения от процесса и быстро выгораете.

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

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

Культ целеориентированности — причина огромного количества депрессий и профессиональной деформации. Можно считать нормальным, когда состоявшиеся профессионалы «выгорают», отказываются от гонки за целями и занимаются ремеслом на Бали. А можно ведь просто до этого не доводить 🙂

Как может быть иначе? Ответим в следующем посте.

#management

Как может быть иначе?

Можно поставить бегуну цель «пробежать стометровку за 9 секунд на ближайшей Олимпиаде». И он будет усердно тренироваться, чтобы ее достичь. Но профессиональный спорт высоких достижений — не наша область деятельности. Но готовы ли мы за достижение карьерных целей постоянно платить здоровьем, важными отношениями и чувством собственного достоинства? Или хотим просто «хорошо себя чувствовать и быстро бегать»? Вероятно, нам лучше действовать от намерения вроде «бегать быстрее».

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

Чем намерение отличается от желания?

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

Итого:
1. Целеполагание — это инструмент реализации собственных намерений. Им нужно пользоваться с умом, там, где он принесет больше пользы чем вреда. Не забывайте задаваться вопросом: «Эти вред / польза возникают в тактической перспективе или в стратегической?». Совсем без целей адекватная жизнь в рынке невозможна. Но лучше не ставить их, чем ставить «плохие».
2. Для благоприятного существования крайне важно соответствие цели внутреннему намерению.
3. В стратегической перспективе намерение приводит к лучшим результатам, чем цепочка целей. При этом с меньшими затратами энергии.

#development #management

В своей работе мы особое внимание уделяем качеству. О подходе к его обеспечению рассказал наш технический директор Рамиль Аминов.

https://habr.com/ru/post/549130/

#development

Бывает, что разработчику жалко выкинуть или переписать свой код. Он шел к нему, писал, тратил своё время. К тому же, задача в таск-трекере сделана и закрыта.

Но в реальности невозможно избежать изменений. Не только потому, что сложно сделать хорошо с первого раза. А потому, что изменения и развитие в «живых» проектах и продуктах — это необходимость. Если не улучшать продукт, то отстанешь от конкурентов.

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

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

В такой парадигме и выкидывать код, как старый хлам, приятно.

#management

Как осознанно подойти к управлению ожиданиями в проектной деятельности? И зачем?

Do и Don't управления ожиданиями в новой статье нашего руководителя отдела по управлению проектами Максима Никитцова.

Открытый микрофон — в комментариях, поделитесь своими принципами, правилами и лайфхаками в управлении ожиданиями!