Вчера было занятие группы будущих руководителей digital-продуктов. В рамках Нетологии. Тема — "техническое задание". В этот раз я решил провести эксперимент. И полностью переделать занятие.
Предыдущие занятия по этой теме выглядели так:
- Много-много систематизированной информации + кейсы из личного опыта
- Треть занятия — практика в командах.
- И дополнительные материалы по теме для самостоятельного обучения.
В этот раз всё было иначе.
Я решил пойти от уровня группы. Провел анкетирование по всем моим темам блока. Оценил общий уровень. Из оценки было видно, что бОльшая часть группы знает тему на достаточно хорошем уровне. После этого решил всё занятие сделать практикой. Чтобы ребята поучились друг у друга.
Придумал, на какой проект будем делать ТЗ. Проект взял самый насущный для HR — сервис-платформу для рекламы вакансий среди IT-специалистов. Разбил его на три компонента — личный кабинет с аналитикой, систему взаимодействия с рекламными каналами и систему генерации лэндингов.
И стартовали.
Поскольку ребят было сильно больше, чем ожидалось в субботу утром, вместо трех команд пришлось сделать четыре. Четвертая играла роль команды программистов. Оппонировала к ТЗ...
С точки зрения некоторых участников получилось, конечно, так себе:
1. Ребята много времени потеряли, чтобы друг с другом договориться. Даже внутри команды. Не говоря уж про "программистов-хейтеров".
2. Многие все же переоценили свой уровень и без систематизации им было сложно.
3. Кто-то вообще пришел без опыта, таким было сложнее всего.
Мне тоже не все понравилось. Не удивлюсь, если на следующем занятии будет сильно меньше людей. Хотя его уже проведу в традиционной форме. Там даже по анкетам это очевидно. Но вообще, я доволен экспериментом. Ведь хотя мало кто понял, как правильно делать ТЗ, почти все почувствовали на своей шкуре, что бывает, когда к нечетким требованиям добавляются проблемы с коммуникацией :)
Выводы простые:
- Everybody lies
- Сбалансированные группы в обучении — лучше.
- Нужно учитывать обратную связь и уметь вовремя остановиться.
- Четкие требования — рулят. Но меньше простора для развития
ФБ: https://www.facebook.com/WebByte/posts/1646845965380143
Предыдущие занятия по этой теме выглядели так:
- Много-много систематизированной информации + кейсы из личного опыта
- Треть занятия — практика в командах.
- И дополнительные материалы по теме для самостоятельного обучения.
В этот раз всё было иначе.
Я решил пойти от уровня группы. Провел анкетирование по всем моим темам блока. Оценил общий уровень. Из оценки было видно, что бОльшая часть группы знает тему на достаточно хорошем уровне. После этого решил всё занятие сделать практикой. Чтобы ребята поучились друг у друга.
Придумал, на какой проект будем делать ТЗ. Проект взял самый насущный для HR — сервис-платформу для рекламы вакансий среди IT-специалистов. Разбил его на три компонента — личный кабинет с аналитикой, систему взаимодействия с рекламными каналами и систему генерации лэндингов.
И стартовали.
Поскольку ребят было сильно больше, чем ожидалось в субботу утром, вместо трех команд пришлось сделать четыре. Четвертая играла роль команды программистов. Оппонировала к ТЗ...
С точки зрения некоторых участников получилось, конечно, так себе:
1. Ребята много времени потеряли, чтобы друг с другом договориться. Даже внутри команды. Не говоря уж про "программистов-хейтеров".
2. Многие все же переоценили свой уровень и без систематизации им было сложно.
3. Кто-то вообще пришел без опыта, таким было сложнее всего.
Мне тоже не все понравилось. Не удивлюсь, если на следующем занятии будет сильно меньше людей. Хотя его уже проведу в традиционной форме. Там даже по анкетам это очевидно. Но вообще, я доволен экспериментом. Ведь хотя мало кто понял, как правильно делать ТЗ, почти все почувствовали на своей шкуре, что бывает, когда к нечетким требованиям добавляются проблемы с коммуникацией :)
Выводы простые:
- Everybody lies
- Сбалансированные группы в обучении — лучше.
- Нужно учитывать обратную связь и уметь вовремя остановиться.
- Четкие требования — рулят. Но меньше простора для развития
ФБ: https://www.facebook.com/WebByte/posts/1646845965380143
Немного про то, как выглядел второй этап "Лидеров России"
https://www.facebook.com/WebByte/posts/1649401875124552
https://www.facebook.com/WebByte/posts/1649401875124552
Разговорились сегодня с представителем HR про оценку 360. Дескать, как проводить-то. Дело новое, незнакомое, что-то читали, а практики нет. По каким компетенциям техдиректора оценивать-то? Погуглить, может? Ну погуглили, узнали про этапы проведения оценки. А что дальше?
Хорошо бы, если б гугл решал за нас. А мы только пожинали плоды. Но нет. Подготовительный этап к 360 — компетентностное моделирование — гугл за вас не сделает. Впрочем, в такой области, как IT, не сильно помогут и проф.стандарты. И вот почему.
Модель компетенций сильно связана с процессами конкретной компании. А я пока не встречал двух компаний с одинаковыми процессами. Ну, я еще зеленый, да, ISO не нюхал. Раз компании разные, то модель одной может не подойти второй — либо будет что-то лишнее, либо чего-то не хватать. Поэтому на чужой опыт можно опираться, не более того.
Компания — живой организм. Кто-то приходит, кто-то уходит, как-то всё в динамике меняется. Меняется и модель компетенций. То, как вы оценивали сейчас, может не работать через год.
Ладно, а HRу-то что делать? Особенно, если на аудит ни времени, ни денег нет?
1. Построение модели начать с небольшой команды, а не сразу со всей компании.
2. Расписать вместе с участниками команды все процессы, в которых они участвуют.
3. Определить, какие из них — ключевые и попрактиковаться на них.
4. Потом определиться, какие знания нужны на каждом этапе процесса. Какие навыки (практики, инструменты). Какие компетенции работы с людьми. Какие роли и люди, в конце концов, участвуют на этих этапах.
5. Систематизировать знания, навыки, софты.
6. Снова понять ключевые.
И вот только после этого считайте, что можно приступать к формированию опросника.
Каким образом его составлять — эт отдельный вопрос, ага.
ФБ: https://www.facebook.com/WebByte/posts/1649700225094717
Хорошо бы, если б гугл решал за нас. А мы только пожинали плоды. Но нет. Подготовительный этап к 360 — компетентностное моделирование — гугл за вас не сделает. Впрочем, в такой области, как IT, не сильно помогут и проф.стандарты. И вот почему.
Модель компетенций сильно связана с процессами конкретной компании. А я пока не встречал двух компаний с одинаковыми процессами. Ну, я еще зеленый, да, ISO не нюхал. Раз компании разные, то модель одной может не подойти второй — либо будет что-то лишнее, либо чего-то не хватать. Поэтому на чужой опыт можно опираться, не более того.
Компания — живой организм. Кто-то приходит, кто-то уходит, как-то всё в динамике меняется. Меняется и модель компетенций. То, как вы оценивали сейчас, может не работать через год.
Ладно, а HRу-то что делать? Особенно, если на аудит ни времени, ни денег нет?
1. Построение модели начать с небольшой команды, а не сразу со всей компании.
2. Расписать вместе с участниками команды все процессы, в которых они участвуют.
3. Определить, какие из них — ключевые и попрактиковаться на них.
4. Потом определиться, какие знания нужны на каждом этапе процесса. Какие навыки (практики, инструменты). Какие компетенции работы с людьми. Какие роли и люди, в конце концов, участвуют на этих этапах.
5. Систематизировать знания, навыки, софты.
6. Снова понять ключевые.
И вот только после этого считайте, что можно приступать к формированию опросника.
Каким образом его составлять — эт отдельный вопрос, ага.
ФБ: https://www.facebook.com/WebByte/posts/1649700225094717
Сегодня поговорим про инциденты. Примерно такой фразой я начал очередное занятие. В течение двух часов мы говорили про управление отклонениями от нормального поведения систем.
Но шутнице-вселенной показалось мало практической работы на лекции. Выйдя из здания, я не обнаружил своей машины на месте, где ее оставил. «Та-дам! Аларм!» — глаза-мониторинг отправили сигнал в мозг. Мозг сразу эскалировал в надпочечники, запросил дозу адреналина. Началась реакция на инцидент.
Одна из основных задач инцидент-менеджмента — быстрая реакция на происходящее. Раньше заметили, раньше среагировали — меньше последствия. Чтобы ускорить реакцию, нужны инструкции — что делать в случае проблем. Нужна как минимум общая инструкция и какое-то количество частных инструкций — для проблем, с которыми уже сталкивались и научились решать.
Общая инструкция в моем случае — смотри в интернет.
Буквально через минуту после осознания, что машины нет, я уже успел открыть приложение Парковок Москвы. Из него еще через несколько секунд узнал, где находится отделение ГИБДД, куда нужно ехать за протоколом. И на какой стоянке находится моя машина.
Итак, после ознакомления с инструкцией стало понятно, что нужно делать дальше:
1. Скататься на стоянку и забрать ОСАГО.
2. Скаться в ГИБДД и получить копию протокола об административном нарушении
3. С этой копией поехать обратно на стоянку и забрать автомобиль.
Сказано — сделано.
Я классифицировал инцидент как "Критический" — потому что нужно было быть дома сильно раньше, чем теперь получалось — и сообщил заинтересованным лицам по предписанным каналам связи. С той стороны трубки сказали то, что обычно говорят заинтересованные сотрудники, когда им сообщаешь, что упала база данных. Слова угадайте сами.
Инструкция была корректной и после нескольких несложных упражнений машина была получена. Ровно через три часа я проехал мимо здания, где читал лекцию. Инцидент был завершен.
Вторая задача инцидент-менеджмента — не допустить повторение инцидента в будущем или хотя бы минимизировать его длительность и стоимость. Для этого обязательно нужно собирать детальную информацию о том, что произошло. Еще — где это случилось, что было предпринято для устранения. Я также рекомендую поминутно расписывать, что происходило во время инцидента. Это сильно помогает при анализе проблем.
Итак, давайте посмотрим по логам (протоколам и моим записям), как развивался инцидент.
- 12:45 — начало инцидента, эвакуация машины
- 14:15 — срабатывание триггера (глаза увидели). Начало работы по инциденту
- 14:45 - 15:00 — я на стоянке, забираю ОСАГО, вызываю такси
- 15:35 - 15:50 — я в ГИБДД, оформляю необходимые бумаги (штраф со скидкой 50% оплачу позднее).
- 16:00 - 16:20 — еду в такси на стоянку
- 16:36 — оплата эвакуакции,
- 16:50 — выехал за пределы стоянки
- 17:15 — проехал мимо Бауманской в сторону дома, инцидент завершен.
При анализе этого инцидента можно заметить, что часть процесса в дальнейшем можно сократить — как минимум, если уж осознанно нарушаю, нужно брать с собой ОСАГО. Это сэкономит около 700-800 р. И где-то час времени.
На следующем занятии по инцидент-менеджменту будет о чем рассказать. А то уж я переживать начал, что повторяю одни и те же случаи. Вселенная, спасибо за качественный материал! Твой юмор я тоже оценил :)
Учитесь управлять инцидентами — экономит время и нервы, учит даже к проблемам относиться спокойно.
ФБ: https://www.facebook.com/WebByte/posts/1652811764783563
Но шутнице-вселенной показалось мало практической работы на лекции. Выйдя из здания, я не обнаружил своей машины на месте, где ее оставил. «Та-дам! Аларм!» — глаза-мониторинг отправили сигнал в мозг. Мозг сразу эскалировал в надпочечники, запросил дозу адреналина. Началась реакция на инцидент.
Одна из основных задач инцидент-менеджмента — быстрая реакция на происходящее. Раньше заметили, раньше среагировали — меньше последствия. Чтобы ускорить реакцию, нужны инструкции — что делать в случае проблем. Нужна как минимум общая инструкция и какое-то количество частных инструкций — для проблем, с которыми уже сталкивались и научились решать.
Общая инструкция в моем случае — смотри в интернет.
Буквально через минуту после осознания, что машины нет, я уже успел открыть приложение Парковок Москвы. Из него еще через несколько секунд узнал, где находится отделение ГИБДД, куда нужно ехать за протоколом. И на какой стоянке находится моя машина.
Итак, после ознакомления с инструкцией стало понятно, что нужно делать дальше:
1. Скататься на стоянку и забрать ОСАГО.
2. Скаться в ГИБДД и получить копию протокола об административном нарушении
3. С этой копией поехать обратно на стоянку и забрать автомобиль.
Сказано — сделано.
Я классифицировал инцидент как "Критический" — потому что нужно было быть дома сильно раньше, чем теперь получалось — и сообщил заинтересованным лицам по предписанным каналам связи. С той стороны трубки сказали то, что обычно говорят заинтересованные сотрудники, когда им сообщаешь, что упала база данных. Слова угадайте сами.
Инструкция была корректной и после нескольких несложных упражнений машина была получена. Ровно через три часа я проехал мимо здания, где читал лекцию. Инцидент был завершен.
Вторая задача инцидент-менеджмента — не допустить повторение инцидента в будущем или хотя бы минимизировать его длительность и стоимость. Для этого обязательно нужно собирать детальную информацию о том, что произошло. Еще — где это случилось, что было предпринято для устранения. Я также рекомендую поминутно расписывать, что происходило во время инцидента. Это сильно помогает при анализе проблем.
Итак, давайте посмотрим по логам (протоколам и моим записям), как развивался инцидент.
- 12:45 — начало инцидента, эвакуация машины
- 14:15 — срабатывание триггера (глаза увидели). Начало работы по инциденту
- 14:45 - 15:00 — я на стоянке, забираю ОСАГО, вызываю такси
- 15:35 - 15:50 — я в ГИБДД, оформляю необходимые бумаги (штраф со скидкой 50% оплачу позднее).
- 16:00 - 16:20 — еду в такси на стоянку
- 16:36 — оплата эвакуакции,
- 16:50 — выехал за пределы стоянки
- 17:15 — проехал мимо Бауманской в сторону дома, инцидент завершен.
При анализе этого инцидента можно заметить, что часть процесса в дальнейшем можно сократить — как минимум, если уж осознанно нарушаю, нужно брать с собой ОСАГО. Это сэкономит около 700-800 р. И где-то час времени.
На следующем занятии по инцидент-менеджменту будет о чем рассказать. А то уж я переживать начал, что повторяю одни и те же случаи. Вселенная, спасибо за качественный материал! Твой юмор я тоже оценил :)
Учитесь управлять инцидентами — экономит время и нервы, учит даже к проблемам относиться спокойно.
ФБ: https://www.facebook.com/WebByte/posts/1652811764783563
Разговорились про то, как определять уровень знаний разработчиков, если язык разработки новый для компании.
Оставим за рамками вопрос "Зачем вообще это нужно?". Бывает. Допустим, нужно. Мне однажды нужно было тестировщика впервые в жизни нанять.
Что же делать? Простой вопрос — простой ответ.
Если каких-то компетенций не хватает, нужно, чтобы их хватало.
Как их получить?
Через обучение — долго. Сначала курсы найти, потом еще разобраться в предмете настолько, чтобы научиться собеседовать.
Самый простой вариант добрать компетенций — найти эксперта в технологии. И пособеседовать с его помощью. Если переживаете, что задергаете эксперта, вот еще варианты:
1. Найдите несколько экспертов, которых сможете привлекать по мере необходимости;
2. Возьмите своего самого сильного программиста, привлеките его на несколько первых собеседований. Пусть учится у эксперта.
3. Возьмите своего самого сильного программиста для изучения новой предметной области. Пусть пообщается с экспертом, поймет, какими инструментами решаются ваши задачи в новой технологии. И пусть проводит собеседования.
4. В конце концов, возьмите кадровое агентство, которое специализируется на IT-специалистах. Если хорошие, то точно умеют собеседовать всех.
Если всё же нашли эксперта — уговорите пособеседовать вместе. Расскажите немного про вашу область. Дайте кандидату решить практический кейс из этой области. Пусть эксперт оценит техническое качество решения, а вы — смысловое.
И не забудьте эксперта поблагодарить. Лучше деньгами.
Он вам еще пригодится.
ФБ: https://www.facebook.com/WebByte/posts/1656068254457914
Оставим за рамками вопрос "Зачем вообще это нужно?". Бывает. Допустим, нужно. Мне однажды нужно было тестировщика впервые в жизни нанять.
Что же делать? Простой вопрос — простой ответ.
Если каких-то компетенций не хватает, нужно, чтобы их хватало.
Как их получить?
Через обучение — долго. Сначала курсы найти, потом еще разобраться в предмете настолько, чтобы научиться собеседовать.
Самый простой вариант добрать компетенций — найти эксперта в технологии. И пособеседовать с его помощью. Если переживаете, что задергаете эксперта, вот еще варианты:
1. Найдите несколько экспертов, которых сможете привлекать по мере необходимости;
2. Возьмите своего самого сильного программиста, привлеките его на несколько первых собеседований. Пусть учится у эксперта.
3. Возьмите своего самого сильного программиста для изучения новой предметной области. Пусть пообщается с экспертом, поймет, какими инструментами решаются ваши задачи в новой технологии. И пусть проводит собеседования.
4. В конце концов, возьмите кадровое агентство, которое специализируется на IT-специалистах. Если хорошие, то точно умеют собеседовать всех.
Если всё же нашли эксперта — уговорите пособеседовать вместе. Расскажите немного про вашу область. Дайте кандидату решить практический кейс из этой области. Пусть эксперт оценит техническое качество решения, а вы — смысловое.
И не забудьте эксперта поблагодарить. Лучше деньгами.
Он вам еще пригодится.
ФБ: https://www.facebook.com/WebByte/posts/1656068254457914
Иногда очень сложно определить тему для очередного поста. Нет, не потому что темы закончились. Запас-то ещё ого-го. Сложно потому, что слишком много всего происходит кругом.
Общаешься с HR и тут же что-нибудь придумаешь написать на тему обратной связи, ответственности, каких-нибудь полезных инструментов подбора. Общаешься с разработчиками - и бац! - тут тебе и про архитектуру что-то, и про нюансы процессов. А ещё про менеджмент что-нибудь философское. Или про осознанность решений. Про картографию и интерпретацию. Много всего.
Большой выбор ничем не лучше отсутствия выбора. Много идей ничем не лучше их отсутствия. Много фич в продукте ничем не лучше сырого продукта.
Вот почему важна обратная связь. Даже тем, кто вещает с табуретки. Фокусироваться помогает. На том, что действительно нужно слушателям-читателям.
Так что не проходите мимо, пишите в вопросы, которые вас сейчас беспокоят. Вдруг что-то да знаю и отвечу.
ФБ: https://facebook.com/WebByte/posts/1659263824138357
Общаешься с HR и тут же что-нибудь придумаешь написать на тему обратной связи, ответственности, каких-нибудь полезных инструментов подбора. Общаешься с разработчиками - и бац! - тут тебе и про архитектуру что-то, и про нюансы процессов. А ещё про менеджмент что-нибудь философское. Или про осознанность решений. Про картографию и интерпретацию. Много всего.
Большой выбор ничем не лучше отсутствия выбора. Много идей ничем не лучше их отсутствия. Много фич в продукте ничем не лучше сырого продукта.
Вот почему важна обратная связь. Даже тем, кто вещает с табуретки. Фокусироваться помогает. На том, что действительно нужно слушателям-читателям.
Так что не проходите мимо, пишите в вопросы, которые вас сейчас беспокоят. Вдруг что-то да знаю и отвечу.
ФБ: https://facebook.com/WebByte/posts/1659263824138357
#РазговорилисьCегодня с одним IT-предпринимателем про технических директоров. Опасается человек, что в случае конфликта с руководством технический директор со всеми его полномочиями может бизнес грохнуть.
Мне почему-то сразу вспомнилась фраза, что «при увольнении рядовые сотрудники уносят с собой информацию, руководители среднего звена — бизнес-процессы, а топ-менеджеры — бизнес». Не совсем в тему, но всё же.
Что тут сказать.
Конечно, если технический директор выстроил процессы так, что вся техника завязана только на него, то шансы получить проблемы при конфликте весьма велики. Люди разные бывают, нервы опять же, стресс. Конечно, если вы зависите от одного человека, то его нужно холить и лелеять. Покупать ему санкционный сыр и в масле катать.
Кстати, лайфхак еще есть — жениться на техдиректоре. Или замуж за него выйти. Главное, правильно транслировать это текущему супругу или супруге: «Извини, солнышко, ничего личного, just business».
Но, конечно, подобная проблема может быть не только с техдиректором. В моей практике бывали случаи, когда бутылочным горлышком, от которого зависел многомиллионный бизнес, был далеко не директор. Ну сложилось так исторически, чо.
Что делать в таком случае? Дублировать. Размывать компетенции, знания, навыки как можно быстрее. Давать денег, если попросит. Шантаж? Да, шантаж. Сами виноваты. Ну или те, кто был до вас. Говорят, долю еще давать можно ключевым сотрудникам, иногда спасает.
Страдать и дублировать. Людьми, инструментами, изменением процессов. Планомерно. Неделя за неделей. Может быть даже в ущерб развитию бизнеса. Это временно, ненадолго. А вот если человека автобус переедет — будет больно. Очень.
Знайте, кто у вас самое узкое место.
Думайте, как это исправить.
Торопитесь.
ФБ: https://www.facebook.com/WebByte/posts/1663398640391542
Мне почему-то сразу вспомнилась фраза, что «при увольнении рядовые сотрудники уносят с собой информацию, руководители среднего звена — бизнес-процессы, а топ-менеджеры — бизнес». Не совсем в тему, но всё же.
Что тут сказать.
Конечно, если технический директор выстроил процессы так, что вся техника завязана только на него, то шансы получить проблемы при конфликте весьма велики. Люди разные бывают, нервы опять же, стресс. Конечно, если вы зависите от одного человека, то его нужно холить и лелеять. Покупать ему санкционный сыр и в масле катать.
Кстати, лайфхак еще есть — жениться на техдиректоре. Или замуж за него выйти. Главное, правильно транслировать это текущему супругу или супруге: «Извини, солнышко, ничего личного, just business».
Но, конечно, подобная проблема может быть не только с техдиректором. В моей практике бывали случаи, когда бутылочным горлышком, от которого зависел многомиллионный бизнес, был далеко не директор. Ну сложилось так исторически, чо.
Что делать в таком случае? Дублировать. Размывать компетенции, знания, навыки как можно быстрее. Давать денег, если попросит. Шантаж? Да, шантаж. Сами виноваты. Ну или те, кто был до вас. Говорят, долю еще давать можно ключевым сотрудникам, иногда спасает.
Страдать и дублировать. Людьми, инструментами, изменением процессов. Планомерно. Неделя за неделей. Может быть даже в ущерб развитию бизнеса. Это временно, ненадолго. А вот если человека автобус переедет — будет больно. Очень.
Знайте, кто у вас самое узкое место.
Думайте, как это исправить.
Торопитесь.
ФБ: https://www.facebook.com/WebByte/posts/1663398640391542
Менеджмент похож на беговые виды спорта в легкой атлетике.
Бывают задачи, где нужно думать о стратегии. Как в марафоне. С наскоку его пробежать не получится. Держишь в голове эти 42 километра и планомерно к ним идешь. Неделя за неделей, месяц за месяцем. Километр за километром.
Бывают задачи, где нужно думать о тактике. Как на средних дистанциях — 800 и 1500. Можно быстро начать, но не добежать. Можно начать спокойно, но не успеть вовремя ускориться. Думать надо.
Бывают задачи, где нужно нестись, что есть сил. Как на стометровке. Или на 400 метрах. Не раздумывая. Просто срываясь с колодок и хренача.
Редкие спортсмены бегают дистанции разных типов.
В основном, специализируются на одних — спринт, средние, длинные.
А что ж тогда от менеджера ожидают способности бегать сразу тремя способами?
ФБ: https://www.facebook.com/WebByte/posts/1666650030066403
Бывают задачи, где нужно думать о стратегии. Как в марафоне. С наскоку его пробежать не получится. Держишь в голове эти 42 километра и планомерно к ним идешь. Неделя за неделей, месяц за месяцем. Километр за километром.
Бывают задачи, где нужно думать о тактике. Как на средних дистанциях — 800 и 1500. Можно быстро начать, но не добежать. Можно начать спокойно, но не успеть вовремя ускориться. Думать надо.
Бывают задачи, где нужно нестись, что есть сил. Как на стометровке. Или на 400 метрах. Не раздумывая. Просто срываясь с колодок и хренача.
Редкие спортсмены бегают дистанции разных типов.
В основном, специализируются на одних — спринт, средние, длинные.
А что ж тогда от менеджера ожидают способности бегать сразу тремя способами?
ФБ: https://www.facebook.com/WebByte/posts/1666650030066403
#РазговорилисьСегодня про развитие сотрудников. И была высказана мысль: «Либо помещаем сотрудников в условия, где они сами развиваются, либо развиваем, либо понимаем,что наша компания — тупая мясорубка и только на перекантоваться». И ответ на эту фразу: «Не бирюза ни разу, но горькая правда жизни».
Я не спец в организационном развитии. Так... Кое-что читал, кое за чем наблюдал, кое с кем дискутировал. Но всё равно этот ответ показался странным. И вот почему.
"Бирюзовость" — не превосходящая форма всех остальных организационных формаций. Она их включает. Как организм не превосходнее отдельного органа или клетки. Более сложный — да. Лучше — нет. Как можно сравнивать печень и сердце? Или кости и мышцы? Они дополняют друг друга, делая работу организма целостной. Как можно сравнивать разные организмы? Они все ценны для матушки-природы.
Если поразмышлять о сходстве устройства «организма» и «организации», то можно прийти к очевидному выводу.
Мясорубка — такая же часть бирюзовой организации, как и зубы в организме млекопитающего. Если для целей развития организма нужно пережевывание пищи, то почему для целей развития организации не может использоваться «мясорубка» в отдельных ее частях? Почему не может использоваться иерархия? Ведь нас окружают тысячи организмов, в которых иерархия — основа. Даже в нашем организме есть жесткая иерархия. Разве менее прекрасен дуб от того, что он весь из себя иерархичен? Разве «парятся» кости стопы, выполняя сигналы из мозга? Нет, у всех свои функции — обеспечить развитие организма. Вместе. Во имя общей цели.
Пожалуйста, не идеализируйте «бирюзу». Это всего лишь более целостная организационная форма. Чуть другая. А не «лучшая».
И да. Если кто-то в России говорит про свою бирюзовость, посмотрите на забор. Там тоже много, что написано. А подходишь поближе — доски.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1669915749739831
Я не спец в организационном развитии. Так... Кое-что читал, кое за чем наблюдал, кое с кем дискутировал. Но всё равно этот ответ показался странным. И вот почему.
"Бирюзовость" — не превосходящая форма всех остальных организационных формаций. Она их включает. Как организм не превосходнее отдельного органа или клетки. Более сложный — да. Лучше — нет. Как можно сравнивать печень и сердце? Или кости и мышцы? Они дополняют друг друга, делая работу организма целостной. Как можно сравнивать разные организмы? Они все ценны для матушки-природы.
Если поразмышлять о сходстве устройства «организма» и «организации», то можно прийти к очевидному выводу.
Мясорубка — такая же часть бирюзовой организации, как и зубы в организме млекопитающего. Если для целей развития организма нужно пережевывание пищи, то почему для целей развития организации не может использоваться «мясорубка» в отдельных ее частях? Почему не может использоваться иерархия? Ведь нас окружают тысячи организмов, в которых иерархия — основа. Даже в нашем организме есть жесткая иерархия. Разве менее прекрасен дуб от того, что он весь из себя иерархичен? Разве «парятся» кости стопы, выполняя сигналы из мозга? Нет, у всех свои функции — обеспечить развитие организма. Вместе. Во имя общей цели.
Пожалуйста, не идеализируйте «бирюзу». Это всего лишь более целостная организационная форма. Чуть другая. А не «лучшая».
И да. Если кто-то в России говорит про свою бирюзовость, посмотрите на забор. Там тоже много, что написано. А подходишь поближе — доски.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1669915749739831
Обратная связь - лучшее, что придумало человечество после изобретения граблей. Потому что грабли по лбу - это физическая боль. А от обратной связи чаще даже приятно.
Обратная связь - отличный инструмент для развития. Ты даёшь обратную связь коллегам, друзьям, родственникам - они растут над собой. По крайней мере шанс на это проявляется. Тебе дают - радуйся и развивайся дальше.
Как чаще всего бывает? По наблюдениям и опыту обратную связь на работе используешь, в основном, для развития. Иногда даже готовишься к очередному сеансу. Проанализируешь действия человека, результаты, на его коммуникации с другими сотрудниками посмотришь. И давай ему по учебникам - сначала плюсы, потом минусы, потом на позитиве заканчиваешь. Методом "гамбургера" это, кажется, называется.
Меж тем иногда этот метод применять не стоит.
Иногда стоит минусами обойтись. Корону сбить. Как граблями.
А иногда просто поддержать нужно, посаппортить. Без всякого развития. Просто потому что хороший. Бывает, что нужно и так. Помогает.
В общем, обратная связь - очень полезный инструмент. Пользуйтесь почаще. Запрашивайте почаще.
Обсудить в ФБ: https://facebook.com/WebByte/posts/1672786796119393
Обратная связь - отличный инструмент для развития. Ты даёшь обратную связь коллегам, друзьям, родственникам - они растут над собой. По крайней мере шанс на это проявляется. Тебе дают - радуйся и развивайся дальше.
Как чаще всего бывает? По наблюдениям и опыту обратную связь на работе используешь, в основном, для развития. Иногда даже готовишься к очередному сеансу. Проанализируешь действия человека, результаты, на его коммуникации с другими сотрудниками посмотришь. И давай ему по учебникам - сначала плюсы, потом минусы, потом на позитиве заканчиваешь. Методом "гамбургера" это, кажется, называется.
Меж тем иногда этот метод применять не стоит.
Иногда стоит минусами обойтись. Корону сбить. Как граблями.
А иногда просто поддержать нужно, посаппортить. Без всякого развития. Просто потому что хороший. Бывает, что нужно и так. Помогает.
В общем, обратная связь - очень полезный инструмент. Пользуйтесь почаще. Запрашивайте почаще.
Обсудить в ФБ: https://facebook.com/WebByte/posts/1672786796119393
Примерно раз в месяц я рассказываю, как проводить декомпозицию.
Беру какой-нибудь пример с небольшим числом требований. На выходе должна появиться последовательность задач, обеспечивающих выполнение этих требований.
Один из этапов декомпозиции — проверка целостности полученного решения. На этапе проверяются два простых правила.
1. Каждому требованию из примера соответствует хотя б одна задача.
2. Нет задач без соответствующих им требований
Первое правило показывает, что мы не забыли учесть ни одно из требований. Второе — что не делаем лишнего.
Вот со вторым правилом постоянно проблемы.
Каждая группа пытается обязательно придумать что-нибудь избыточное. Вот, к примеру, есть задание "Организовать перелет из Москвы в Лондон". Так обязательно предложат купить обратный билет. Или обязательно задумаются о негабаритном багаже.
Любим мы переусложнять, ага.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1676173999114006
Беру какой-нибудь пример с небольшим числом требований. На выходе должна появиться последовательность задач, обеспечивающих выполнение этих требований.
Один из этапов декомпозиции — проверка целостности полученного решения. На этапе проверяются два простых правила.
1. Каждому требованию из примера соответствует хотя б одна задача.
2. Нет задач без соответствующих им требований
Первое правило показывает, что мы не забыли учесть ни одно из требований. Второе — что не делаем лишнего.
Вот со вторым правилом постоянно проблемы.
Каждая группа пытается обязательно придумать что-нибудь избыточное. Вот, к примеру, есть задание "Организовать перелет из Москвы в Лондон". Так обязательно предложат купить обратный билет. Или обязательно задумаются о негабаритном багаже.
Любим мы переусложнять, ага.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1676173999114006
Идеальные требования наглядны.
Так я начинаю один из блоков занятия про техническое задание в рамках преподавания в «Нетология» и ВШБИ.
Уже почти нет возражений, что хорошая диаграмма заменяет много текста. Понемногу понимают, что современное поколение программистов не любит читать большие тексты, но вполне нормально относится к картинкам, схемам и диаграммам. Одна диаграмма вполне заменяет 3-4 абзаца текста.
Уже никто не спорит с тем, что в хорошем ТЗ должны быть прототипы. Спрашивают разве что, какими инструментами их делать. Я рассказываю про всякие Sketch или Figma, про сервисы рисования схем и диаграмм. Вроде Draw.io или Gliffty. Даже про Tilda рассказываю как средство прототипирования. А чо, можно и на ней собрать.
Но вот слайд про то, что для пользовательских сценариев и прототипирования можно использовать простейшие подручные вещи — типа маркерной доски, стикеров или бумаги — иногда вызывает легкую усмешку. А зря. Теплая ламповая бумага вполне рулит, когда что-то нужно быстро нарисовать. Салфетки часто под рукой. А вот онлайн-инструменты не всегда.
Кстати, на маркерной доске отлично можно изобразить план запуска проекта, даже если проект очень длительный. Главное, чтобы 3-4 разноцветных маркера были под рукой. И уборщица не стерла ваш замечательный план.
А как вы делаете прототипы и пользовательские сценарии?
Ответить в ФБ: https://www.facebook.com/WebByte/posts/1679021618829244
Так я начинаю один из блоков занятия про техническое задание в рамках преподавания в «Нетология» и ВШБИ.
Уже почти нет возражений, что хорошая диаграмма заменяет много текста. Понемногу понимают, что современное поколение программистов не любит читать большие тексты, но вполне нормально относится к картинкам, схемам и диаграммам. Одна диаграмма вполне заменяет 3-4 абзаца текста.
Уже никто не спорит с тем, что в хорошем ТЗ должны быть прототипы. Спрашивают разве что, какими инструментами их делать. Я рассказываю про всякие Sketch или Figma, про сервисы рисования схем и диаграмм. Вроде Draw.io или Gliffty. Даже про Tilda рассказываю как средство прототипирования. А чо, можно и на ней собрать.
Но вот слайд про то, что для пользовательских сценариев и прототипирования можно использовать простейшие подручные вещи — типа маркерной доски, стикеров или бумаги — иногда вызывает легкую усмешку. А зря. Теплая ламповая бумага вполне рулит, когда что-то нужно быстро нарисовать. Салфетки часто под рукой. А вот онлайн-инструменты не всегда.
Кстати, на маркерной доске отлично можно изобразить план запуска проекта, даже если проект очень длительный. Главное, чтобы 3-4 разноцветных маркера были под рукой. И уборщица не стерла ваш замечательный план.
А как вы делаете прототипы и пользовательские сценарии?
Ответить в ФБ: https://www.facebook.com/WebByte/posts/1679021618829244
Должна ли быть открытой информация о зарплатах в компании?
Есть ли однозначный ответ на этот вопрос? Если не должна, то как это сочетается с заявлениями компании о "прозрачности"? Если должна, то как объяснить, почему у Марьванны зарплата выше, чем у Сансаныча? Вот, говорят, даже в Morning Star информация о зарплатах закрыта. Хотя вродь осознанность высокая у сотрудников. В книжках про них пишут, ага-ага.
А должна ли быть прозрачна вилка зарплаты на грейде? А то, на каком грейде находится сотрудник?
А должна ли быть прозрачность в том, насколько компания в зарплатах соответствует рынку? А должность в компании насколько?
А должна ли бы прозрачна информация о зарплатах в отрасли и профессиях?
Вот Яндекс считает, что не должна.
И закрыл свой сервис про зарплаты: "К сожалению, данный раздел был закрыт и больше не поддерживается. Его возвращение не планируется.".
Пойду, слайд из презентации удалю. Устарела.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1681836321881107
Есть ли однозначный ответ на этот вопрос? Если не должна, то как это сочетается с заявлениями компании о "прозрачности"? Если должна, то как объяснить, почему у Марьванны зарплата выше, чем у Сансаныча? Вот, говорят, даже в Morning Star информация о зарплатах закрыта. Хотя вродь осознанность высокая у сотрудников. В книжках про них пишут, ага-ага.
А должна ли быть прозрачна вилка зарплаты на грейде? А то, на каком грейде находится сотрудник?
А должна ли быть прозрачность в том, насколько компания в зарплатах соответствует рынку? А должность в компании насколько?
А должна ли бы прозрачна информация о зарплатах в отрасли и профессиях?
Вот Яндекс считает, что не должна.
И закрыл свой сервис про зарплаты: "К сожалению, данный раздел был закрыт и больше не поддерживается. Его возвращение не планируется.".
Пойду, слайд из презентации удалю. Устарела.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1681836321881107
Стадии развития программиста.
Стадия первая.
Я ничего не знаю, ничего не умею, боюсь ошибиться.
Поэтому я внимательно буду смотреть на окружающих, подражать, слушать советы сеньоров. А еще буду с опаской относиться к тем, кто плывет против течения. И помогать старшим от таких отбиваться. Менеджеры — враги!
Стадия вторая.
Хо-хо. Я сделал свой первый крупный проект.
Вы говорите, что он плох? Сперва добейтесь. Вы говорите, что ваш язык или фреймворк лучше? Вы просто ничего не понимаете. Вы просите меня попробовать новое? А зачем? Ведь и так всё работает. Вы против рефакторинга? Фаулера почитайте. И вообще, сколько шаблонов проектирования вы знаете? Ах, вы вообще не программист? Ну что же, ваше мнение меня не интересует. Совсем.
Стадия третья.
Новый язык? Давайте попробуем. Новый фреймворк? Тащите сюда. Что? Вот этот код плох? Ок, как лучше? Спасибо! Какая книжка вышла? ОК, почитаю. Реакт позволяет сделать быстрее? Берем реакт, в топку ангуляр.
Стадия четвертая
Нет одинаковых программистов. Нет одинаковых проектов. Нужно думать. Нет правильных схем, нет идеального кода, есть код, который в данное время в данном проекте позволяет сделать так, чтобы не было мучительно больно хотя б первые несколько месяцев, потом всё равно поменяется. Плавали — знаем.
По ощущениям многие застревают между второй и третьей. Единицы доходят до четвертой.
А вы на какой? Отмечайтесь в ФБ: https://www.facebook.com/WebByte/posts/1684757458255660
Стадия первая.
Я ничего не знаю, ничего не умею, боюсь ошибиться.
Поэтому я внимательно буду смотреть на окружающих, подражать, слушать советы сеньоров. А еще буду с опаской относиться к тем, кто плывет против течения. И помогать старшим от таких отбиваться. Менеджеры — враги!
Стадия вторая.
Хо-хо. Я сделал свой первый крупный проект.
Вы говорите, что он плох? Сперва добейтесь. Вы говорите, что ваш язык или фреймворк лучше? Вы просто ничего не понимаете. Вы просите меня попробовать новое? А зачем? Ведь и так всё работает. Вы против рефакторинга? Фаулера почитайте. И вообще, сколько шаблонов проектирования вы знаете? Ах, вы вообще не программист? Ну что же, ваше мнение меня не интересует. Совсем.
Стадия третья.
Новый язык? Давайте попробуем. Новый фреймворк? Тащите сюда. Что? Вот этот код плох? Ок, как лучше? Спасибо! Какая книжка вышла? ОК, почитаю. Реакт позволяет сделать быстрее? Берем реакт, в топку ангуляр.
Стадия четвертая
Нет одинаковых программистов. Нет одинаковых проектов. Нужно думать. Нет правильных схем, нет идеального кода, есть код, который в данное время в данном проекте позволяет сделать так, чтобы не было мучительно больно хотя б первые несколько месяцев, потом всё равно поменяется. Плавали — знаем.
По ощущениям многие застревают между второй и третьей. Единицы доходят до четвертой.
А вы на какой? Отмечайтесь в ФБ: https://www.facebook.com/WebByte/posts/1684757458255660
Люди идут на людей.
Люди покупают товары по рекомендациям других людей. Читают отзывы, читают обзоры. Вакансия IT-специалиста — товар.
Люди идут в компании, в которых работают известные им люди. Или о которых позитивно пишут эксперты, мнение которых ценно для читателя.
Поэтому скоро IT-рекрутеры сделают следующий шаг в осознании роли маркетинга в подборе: работа с лидерами мнений может ускорить и удешевить найм.
Размещение вакансии в посте или канале у известного программиста станет нормой. Нормой станет включение топовых IT-блоггеров в продвижение HR-бренда компании. Крупные компании будут заключать контракты с известными медийными программистами на использование своей символики — одежды, наклеек — на мероприятиях. Появятся кадровые агентства, которые начнут специализироваться на работе с такими программистами. А потом и маркетплейс кто-нибудь соорудит на эту тему.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1687453624652710
Люди покупают товары по рекомендациям других людей. Читают отзывы, читают обзоры. Вакансия IT-специалиста — товар.
Люди идут в компании, в которых работают известные им люди. Или о которых позитивно пишут эксперты, мнение которых ценно для читателя.
Поэтому скоро IT-рекрутеры сделают следующий шаг в осознании роли маркетинга в подборе: работа с лидерами мнений может ускорить и удешевить найм.
Размещение вакансии в посте или канале у известного программиста станет нормой. Нормой станет включение топовых IT-блоггеров в продвижение HR-бренда компании. Крупные компании будут заключать контракты с известными медийными программистами на использование своей символики — одежды, наклеек — на мероприятиях. Появятся кадровые агентства, которые начнут специализироваться на работе с такими программистами. А потом и маркетплейс кто-нибудь соорудит на эту тему.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1687453624652710
Тяжело постоянно быть готовым к переменам, правда?
Тяжело пробовать новые технологии или продукты, изменять процессы, изучать новые методики, делать пилотные проекты.
Ведь так просто придумать множество причин, почему свежая методика не заработает. Ну как же. Мы же такие уникальные, у нас тут все иначе. Сперва поработайте у нас годик.
Методика не решает всех наших проблем, а только половину? Это негодная методика, нет смысла даже начинать.
И вообще, "работает - не трогай". Это неважно, какие последствия будут для компании, если не попробовать. Своя-то рубаха ближе к телу.
"Стой! Остановись! Предвижу большие потери энергии!" - начинает сигнализировать мозг. И тут же переходит в режим энергосбережения и прокрастинации.
Как? Вы не сделаете всего? Нужно будет ещё и самим работать? Не, мы так не хотим. Ответственность же брать придется. Да и вообще - столько дел, столько дел. Приходите завтра. А лучше, в следующем году".
Так и живём, правда?
Откладываем назавтра, на понедельник, на январь следующего года.
Так вот, настал январь-то. Если что-то откладывали, пора б уже начать. Не жалейте мозг, он вам потом "спасибо" скажет.
Тяжело пробовать новые технологии или продукты, изменять процессы, изучать новые методики, делать пилотные проекты.
Ведь так просто придумать множество причин, почему свежая методика не заработает. Ну как же. Мы же такие уникальные, у нас тут все иначе. Сперва поработайте у нас годик.
Методика не решает всех наших проблем, а только половину? Это негодная методика, нет смысла даже начинать.
И вообще, "работает - не трогай". Это неважно, какие последствия будут для компании, если не попробовать. Своя-то рубаха ближе к телу.
"Стой! Остановись! Предвижу большие потери энергии!" - начинает сигнализировать мозг. И тут же переходит в режим энергосбережения и прокрастинации.
Как? Вы не сделаете всего? Нужно будет ещё и самим работать? Не, мы так не хотим. Ответственность же брать придется. Да и вообще - столько дел, столько дел. Приходите завтра. А лучше, в следующем году".
Так и живём, правда?
Откладываем назавтра, на понедельник, на январь следующего года.
Так вот, настал январь-то. Если что-то откладывали, пора б уже начать. Не жалейте мозг, он вам потом "спасибо" скажет.
Интересная штука - шаблоны поведения. Когда-то мозг поймал удачную конфигурацию нейронов и сигналов, которая позволила сэкономить ему энергию, получив нужный результат. Попробовав ещё и ещё, мозг окончательно понял, что эта последовательность нервной деятельности позволяет решать проблему. Родился шаблон поведения. Попадая в похожие ситуации, мозг первым делом пробовал этот успешный шаблон.
Жил-был ребенок, владелец этого мозга.
Когда ребенок был маленьким, он заболел. Ничего серьезного - просто немного кашлял. Мама малыша не бросила его в беде, была с ним, уделяла ему внимание и вылечила его. Не заметив, что у мозга появился шаблон "если кашлять, появится мама и уделит внимание".
Шли годы, ребенок рос. И в семье случилось пополнение - у ребенка появился братик или сестричка. Внезапно ребенок стал получать меньше внимания мамы. Ребенок расстроился. Мозг тоже расстроился. Но он очень любил своего владельца, поэтому вспомнил про старый добрый метод: "если кашлять, появится мама и уделит внимание". И послал последовательность сигналов по подходящим нейронам. Ребенок закашлял, мама переключилась с нового ребенка на него.
Ребенок продолжил кашлять, мама заволновалась, начала таскать по врачам. Но бронхита не нашли. Астмы тоже. Сводили к аллергологу, он прописал таблетки. Но и они не помогли. Ребенок продолжал покашливать. Бедная мама разрывалась между двумя детьми...
Первенец не был виноват в том, что в его мозгу был этот шаблон. Он не был виноват в том, что мозг просто не знал других способов привлечь внимание мамы. Он и слово "психосоматика" не знал. Просто продолжал бессознательно покашливать днём и вполне нормально спать ночью, когда внимание мамы было уже не так нужно.
Вот такая вот интересная загогулина.
Интересно, будет ли мозг использовать этот же шаблон, когда владелец вырастет и ему будет не хватать внимания руководителя?
Обсудить в ФБ: https://facebook.com/WebByte/posts/1694787110586028
Жил-был ребенок, владелец этого мозга.
Когда ребенок был маленьким, он заболел. Ничего серьезного - просто немного кашлял. Мама малыша не бросила его в беде, была с ним, уделяла ему внимание и вылечила его. Не заметив, что у мозга появился шаблон "если кашлять, появится мама и уделит внимание".
Шли годы, ребенок рос. И в семье случилось пополнение - у ребенка появился братик или сестричка. Внезапно ребенок стал получать меньше внимания мамы. Ребенок расстроился. Мозг тоже расстроился. Но он очень любил своего владельца, поэтому вспомнил про старый добрый метод: "если кашлять, появится мама и уделит внимание". И послал последовательность сигналов по подходящим нейронам. Ребенок закашлял, мама переключилась с нового ребенка на него.
Ребенок продолжил кашлять, мама заволновалась, начала таскать по врачам. Но бронхита не нашли. Астмы тоже. Сводили к аллергологу, он прописал таблетки. Но и они не помогли. Ребенок продолжал покашливать. Бедная мама разрывалась между двумя детьми...
Первенец не был виноват в том, что в его мозгу был этот шаблон. Он не был виноват в том, что мозг просто не знал других способов привлечь внимание мамы. Он и слово "психосоматика" не знал. Просто продолжал бессознательно покашливать днём и вполне нормально спать ночью, когда внимание мамы было уже не так нужно.
Вот такая вот интересная загогулина.
Интересно, будет ли мозг использовать этот же шаблон, когда владелец вырастет и ему будет не хватать внимания руководителя?
Обсудить в ФБ: https://facebook.com/WebByte/posts/1694787110586028
#РазговорилисьСегодня о том, что большое количество знаний и навыков мешает менеджеру достигать выдающихся результатов. Дескать, больше знаешь - больше рисков видишь. И не пробуешь что-то внедрять, поскольку сразу видишь проблемы. Но на самом деле можешь просто раз за разом упускать возможности. А необремененный знаниями - якобы - не парится и просто много экспериментирует, пока не нащупает правильный путь.
Давайте посмотрим на это утверждение с точки зрения людей, находящихся на разной стадии развития личности.
Итак, стадия первая: "я - часть группы".
Боязнь ошибки на этой стадии происходит из-за боязни быть выброшенным из группы. Принятие рискованных решений возможно, если так принято в группе.
Стадия вторая: "я - эксперт, я выше остальных".
Боязнь ошибки - из-за боязни потерять свой статус и снова вернуться в глазах других в ту группу, из которой выделился знаниями. Риск возможен, если есть шанс стать ещё большим экспертом в глазах окружающих.
Стадия третья: "любые средства хороши ради результата".
Боязнь риска - из-за боязни не достичь результата. Но чем больше знаний и навыков, тем больше путей ведут к результату. И ошибки на пути просто корректируют направление. Поэтому риск вполне допустим, пока виден хотя б один путь к нужному результату. Ну или же отсутствие пути означает достижение какого-то более важного результата.
Остальные стадии относятся к знаниям как к возможностям и меньше парятся о рисках совершить ошибку.
Понимая страхи каждой стадии, можно развивать привычку рисковать, несмотря на количество знаний и навыков. Или наоборот - заставлять задумываться о рисках чуть больше.
Давайте посмотрим на это утверждение с точки зрения людей, находящихся на разной стадии развития личности.
Итак, стадия первая: "я - часть группы".
Боязнь ошибки на этой стадии происходит из-за боязни быть выброшенным из группы. Принятие рискованных решений возможно, если так принято в группе.
Стадия вторая: "я - эксперт, я выше остальных".
Боязнь ошибки - из-за боязни потерять свой статус и снова вернуться в глазах других в ту группу, из которой выделился знаниями. Риск возможен, если есть шанс стать ещё большим экспертом в глазах окружающих.
Стадия третья: "любые средства хороши ради результата".
Боязнь риска - из-за боязни не достичь результата. Но чем больше знаний и навыков, тем больше путей ведут к результату. И ошибки на пути просто корректируют направление. Поэтому риск вполне допустим, пока виден хотя б один путь к нужному результату. Ну или же отсутствие пути означает достижение какого-то более важного результата.
Остальные стадии относятся к знаниям как к возможностям и меньше парятся о рисках совершить ошибку.
Понимая страхи каждой стадии, можно развивать привычку рисковать, несмотря на количество знаний и навыков. Или наоборот - заставлять задумываться о рисках чуть больше.
#РазговорилисьСегодня про объем времени, который следует выделять на инфраструктурную разработку. На всякие там внутренние инструменты, мониторинг, рефакторинг и прочее.
Идеально, конечно, выделять не просто время, а людей. Или команду. Чтоб только этим и занимались. На постоянной основе, а не время от времени.
Но если так не получается, можно и время выделять. Квотировать, так сказать.
На что обычно уходит время разработчика?
На четыре группы задач:
- Разработка новых фич продукта
- Операционная деятельность
- Разработка инфраструктуры продукта
- Поддержка пользователей
Некоторые компании забивают болт на некоторые группы. За что потом и расплачиваются. Но я знаю именно четыре группы. Может ещё и забиваю на другие.
Операционная деятельность - это всякие мелкие задачки по сопровождению продукта - что-то настроить, что-то быстро посчитать итп. Ещё - время на ритуалы: встречи, декомпозицию задач, планирование, консультирование сотрудников итп.
Поддержка пользователей - это решение вопросов там, где не справилась первая линия суппорта.
Так вот по опыту для нормального развития продукта подходит такая структура квот:
- 45% - продукт
- 15% - операционка
- 20% - инфраструктура
- 20% - поддержка
Конечно, в конкретной компании в конкретной команде в конкретное время структура будет иной. Например, если многие месяцы забивали на инфраструктуру, то через какое-то время разработка станет настолько неповоротливой, что без рефакторинга архитектуры и кода time to market станет просто ужасным. В крайне запущенных случаях придется тратить на инфраструктуру до 60%. И страдать.
Представляете? Только 25% останется на развитие продукта и поддержку! Эт если ещё в компании не практикуются совещания по поводу и без.
В общем, планируйте разработку правильно. А лучше заведите отдельные команды)
Предложить свою структуру: https://facebook.com/WebByte/posts/1701046343293438
Идеально, конечно, выделять не просто время, а людей. Или команду. Чтоб только этим и занимались. На постоянной основе, а не время от времени.
Но если так не получается, можно и время выделять. Квотировать, так сказать.
На что обычно уходит время разработчика?
На четыре группы задач:
- Разработка новых фич продукта
- Операционная деятельность
- Разработка инфраструктуры продукта
- Поддержка пользователей
Некоторые компании забивают болт на некоторые группы. За что потом и расплачиваются. Но я знаю именно четыре группы. Может ещё и забиваю на другие.
Операционная деятельность - это всякие мелкие задачки по сопровождению продукта - что-то настроить, что-то быстро посчитать итп. Ещё - время на ритуалы: встречи, декомпозицию задач, планирование, консультирование сотрудников итп.
Поддержка пользователей - это решение вопросов там, где не справилась первая линия суппорта.
Так вот по опыту для нормального развития продукта подходит такая структура квот:
- 45% - продукт
- 15% - операционка
- 20% - инфраструктура
- 20% - поддержка
Конечно, в конкретной компании в конкретной команде в конкретное время структура будет иной. Например, если многие месяцы забивали на инфраструктуру, то через какое-то время разработка станет настолько неповоротливой, что без рефакторинга архитектуры и кода time to market станет просто ужасным. В крайне запущенных случаях придется тратить на инфраструктуру до 60%. И страдать.
Представляете? Только 25% останется на развитие продукта и поддержку! Эт если ещё в компании не практикуются совещания по поводу и без.
В общем, планируйте разработку правильно. А лучше заведите отдельные команды)
Предложить свою структуру: https://facebook.com/WebByte/posts/1701046343293438
На полуфинале "Лидеров России" (по ЦФО) было голосование.
У участников спрашивали, с чем ассоциируются два слова — "лидерство" и "ответственность".
По мнению участников, "лидерство" — это "вдохновлять".
А вот "ответственность" — это "наказание".
Вот такая у нас память предков, вот так культура общества влияет на подсознание.
Хотите больше ответственности от сотрудников? Меняйте их отношение, меняйте их ассоциации.
У участников спрашивали, с чем ассоциируются два слова — "лидерство" и "ответственность".
По мнению участников, "лидерство" — это "вдохновлять".
А вот "ответственность" — это "наказание".
Вот такая у нас память предков, вот так культура общества влияет на подсознание.
Хотите больше ответственности от сотрудников? Меняйте их отношение, меняйте их ассоциации.