Блог Управление разработкой | OTUS
👋 Канал OTUS в Telegram!
Посты от приглашенных гостей из IT-тусовки, полезные статьи, подборки вакансий от партнеров ➞
Подробнее

Курсы

Программирование
Vue.js разработчик
-40%
React.js разработчик
-40%
Архитектор программного обеспечения
-40%
Архитектура и шаблоны проектирования
-40%
Разработчик C++
-40%
Fullstack разработчик JavaScript
-40%
Backend-разработчик на PHP
-30%
Алгоритмы и структуры данных
-30%
Team Lead
-30%
Разработчик Python. Базовый курс
-30%
Разработчик Python. Продвинутый курс
-22%
iOS Разработчик. Продвинутый курс
-21%
CI/CD
-37%
Разработчик C#
-25%
PostgreSQL Framework Laravel Web-разработчик на Python Разработчик программных роботов (RPA) на базе UiPath и PIX Разработчик игр на Unity Agile Project Manager в IT Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02
Посты
Влияние культуры компании на привлечение и сохранение сотрудников

DevHead_Deep_29.10_site-5020-47ae52.png

В программе курса “Руководитель разработки” мы уделяем достаточно внимания вопросу влияния корпоративной культуры на успешность сотрудников по отдельности и на эффективность команд разработки в целом. Давайте подробнее поговорим об аспектах влияния корпоративной культуры на процессы в компаниях и основные точки развития культуры.

Что делать, если сотрудник не справляется с задачами?

DevHead_Deep_31.07_2_site.png

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

Конечно, возможны разные варианты. В данной заметке рассмотрим один из наиболее «управленческих» – несогласованность уровня постановки задачи делегирования с уровнем компетентности сотрудника (в конкретной области).

Эмерджентность и/или управление группой

DevHead_Deep_31.07_site.png

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

А вот если речь идёт о групповом поиске решения, то тут дело одной демотивацией из-за недоверия не ограничивается – под угрозой может оказаться качество решения.

Итак, какие решение должен принимать руководитель, а какие решения должна принимать группа? Стоит ли принимать всё на себя или лучше оставить всё на откуп группе? И где находится эта граница?

Как меньше ошибаться: советы бывалого

DevHead_Deep_LAST_23.07_site.png

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

За хирургов говорить не буду, расскажу про себя. Я допускаю такие ошибки в двух случаях: – когда я сильно на чём-то сосредоточен – когда я, наоборот, вынужден делать «десять» дел одновременно и/или быстро.

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

Несколько слов об эволюции менеджмента

DevHead_Deep_13.07_site.png

Порою отдельные элементы мотивационных программ потрясают даже моё, весьма богатое, воображение: бутеры с безлактозным(!) сыром (есть люди, для которых это важно), обязательное присутствие в офисе 4 дня в неделю из пяти (есть люди, для которых это не важно?) и так далее.

А уж у работодателей не из «большой N-ки» вообще, простите, крышу рвёт. И с каждым днём появляются всё новые и новые фишки: спортзалы, скидки в барах, гаджеты, такси за счёт компании – ставки растут. Понятно, что это относится не ко всем и встречается не везде, но мы сейчас про «сливки IT».

Первое, кажущееся логичным, объяснение – работники зажрались, а работодатель потерял хватку и ему сели на шею. Это версия объясняет многое, но у меня есть другая, хотя и не менее утрированная.

О разрушительной силе мелочей: в чём проблема?

DevHead_Deep_LAST_11.07_4_site.png

Начну с банальности: разработка ПО — деятельность плохо предсказуемая. Трудно с высокой точностью определить объём предстоящих работ и предугадать все «узкие» и «скользкие» места. Это происходит из-за того, что самой области свойственна высокая неопределённость и изменчивость, поэтому, даже имея на руках детализированный план действий, можно с уверенностью сказать, что что-нибудь пойдёт не так.

Эрик Бёрн «Разработчикам» или «Трансактный анализ на примерах». Часть 2

DevHead_Deep_LAST_11.07_3_site.png

В первой заметке мы рассмотрели дополняющие или параллельные трансакции. И с ними всё было просто, потому что оба человека «играли» в одну и ту же «игру». Например, «Взрослый» первого обращался к «Взрослому» второго и «Взрослый» второго отвечал «Взрослому» первого. Надо сказать, что общение в рамках дополняющих трансакций может происходить довольно долго, потому что всех всё устраивает. А если согласованности нет?

Эрик Бёрн «Разработчикам» или «Трансактный анализ на примерах». Часть 1

DevHead_Deep_LAST_11.07_1_site.png

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

Самоисполняющиеся пророчества в управлении

DevHead_Deep_10.07_Site.png

Термин «самоисполняющееся пророчество» слышали, наверное, все. Но я на всякий случай дам определение из Википедии:

«Самоисполняющееся пророчество — ложное определение ситуации, вызывающее новое поведение, которое превращает первоначальное ложное представление в реальность».

Если не очень понятно, о чём идет речь, приведённый ниже пример расставит всё по местам, потому что речь пойдёт о самоисполняющемся пророчестве или проклятии управленца. Но для начала будет уместно вспомнить «Теорию X и теорию Y» МакГрегора.