Comments 18
Что дает мне офис?
1) Быстродействие и стабильность внутренних сервисов и информационных систем компании
2) Визуальный контакт и понимание, когда лучше обратиться к коллеге/руководителю.
3) Режим, изоляцию от домашних дел, смену обстановки
4) Возможность конфиденциального общения
5) Возможность прямого взаимодействия в группе
6) Реализацию социальных потребностей
7) Слухи
…
Все ли из этого доступно моим работникам дома? И чего не хватает, регламентов ли или показателей?
Мое мнение по пунктам, (мои комментарии в скобках курсивом):
Что дает мне офис?
1) Быстродействие и стабильность внутренних сервисов и информационных систем компании
(С этим разобраться просто. Инфраструктура меняется проще процессов.)
2) Визуальный контакт и понимание, когда лучше обратиться к коллеге/руководителю.
(Это надо зашивать в процесс. Либо делать проще процесс, либо чаще ставить точки контроля.)
3) Режим, изоляцию от домашних дел, смену обстановки
(С этим в наших условиях ничего ни поделаешь. Если дисциплиной можно заставить себя не ходить на кухню 4 часа в сутки, то изолировать рабочее место от жены и детей в условиях 20 метров жилой площади вряд ли получится.)
4) Возможность конфиденциального общения
(Не очень понимаю. Куда уж более скрыто, когда оба в наушниках и гарнитурах и у себя дома.)
5) Возможность прямого взаимодействия в группе
(Прямое взаимодействие переходит в режим ВКС. И здесь сложностей нет.)
6) Реализацию социальных потребностей
(Человек реально ломается, когда не знает, есть ли люди рядом или нет. Например Робинзон Крузо, в реальности стал бы больным через месяц. Когда же есть понимание, что ты часть живого социума, просто далеко от него, ничего ни происходит. Вспомните, космонавтов, они далеко, но на связи.)
7) Слухи
(Для таких вещей можно завести общий чат, и как бывает 2 — «чат с руководителем», «чат без руководителя».)
Что дает мне офис?
1) Быстродействие и стабильность внутренних сервисов и информационных систем компании
(С этим разобраться просто. Инфраструктура меняется проще процессов.)
2) Визуальный контакт и понимание, когда лучше обратиться к коллеге/руководителю.
(Это надо зашивать в процесс. Либо делать проще процесс, либо чаще ставить точки контроля.)
3) Режим, изоляцию от домашних дел, смену обстановки
(С этим в наших условиях ничего ни поделаешь. Если дисциплиной можно заставить себя не ходить на кухню 4 часа в сутки, то изолировать рабочее место от жены и детей в условиях 20 метров жилой площади вряд ли получится.)
4) Возможность конфиденциального общения
(Не очень понимаю. Куда уж более скрыто, когда оба в наушниках и гарнитурах и у себя дома.)
5) Возможность прямого взаимодействия в группе
(Прямое взаимодействие переходит в режим ВКС. И здесь сложностей нет.)
6) Реализацию социальных потребностей
(Человек реально ломается, когда не знает, есть ли люди рядом или нет. Например Робинзон Крузо, в реальности стал бы больным через месяц. Когда же есть понимание, что ты часть живого социума, просто далеко от него, ничего ни происходит. Вспомните, космонавтов, они далеко, но на связи.)
7) Слухи
(Для таких вещей можно завести общий чат, и как бывает 2 — «чат с руководителем», «чат без руководителя».)
Или делать ни правильно, ни задавая вопроса, потому что задать вопрос сложно
… НЕ правильно, НЕ задавая вопроса...
Простите.
Да, наша практика удаленной работы показала, что в этой системе руководитель — самое слабое звено.
Чисто психологически люди оказались неготовыми к новым условиям работы.
Вместо формулировки четких указаний и задач (в письменном виде) — в буквальном смысле многочасовые переливания из пустого в порожнее по Zoom.
Потому как удаленно плохо видна реакция сотрудников — в нормальных условиях мелкая мимика выдает, а на экране ноута/смарта — окошки слишком мелкие :)
Чисто психологически люди оказались неготовыми к новым условиям работы.
Вместо формулировки четких указаний и задач (в письменном виде) — в буквальном смысле многочасовые переливания из пустого в порожнее по Zoom.
Потому как удаленно плохо видна реакция сотрудников — в нормальных условиях мелкая мимика выдает, а на экране ноута/смарта — окошки слишком мелкие :)
Не понимаю таких статей. Последние годы работаю из дома, и я против даже аудио-видео звонков — все что надо должно быть написано в тикетах, документации, если буквами не написано — этого не существует. Без «глаза-в-глаза» работать не могут, невероятно.
UFO just landed and posted this here
Как это будет работать, можно использовать с любого пункта.
1. Требуется обязательное наличие сотрудника с ролью — архитектор/ведущий специалист по компетенции необходимой для решения задачи. Количество сотрудников будет влиять только на скорость достижения этапов решения. Желательно наличие системы постановки задач(jira), таймменеджмента, документооборота, система контроля версий(git).
2. Перед работой необходимо определиться с уровнями задач их стоимостью и сроками реализации. Например «архитекторская» — декомпозиция требований из ТЗ на блоки (передача данных, хранение, обработка и выдача, технологии, библиотеки), составление обоснования на решение задачи, задачи для исполнителей, сроки исполнения, время 14 рабочих дней, стоимость — 50 000 руб. «ведущий/сеньёр» — декомпозиция блока на модули, документ с обоснованием, постановка задач, сроки реализации.
3. Установить единные правила в работе с кодом(code convention), приоритет на подробное документирование и «чистый» код функций и классов. Приоритет простоте вместо сложных языковых конструкций.
4. Определение матрицы компетенций и роли доступных сотрудников и/или находящихся в резерве (удалёнщиков/фрилансеров). В системе постановке задач сотрудник должен видеть весь список задач по своим компетенциям и роли +- один шаг.
5. Принять концепцию рейтинга сотрудника — ошибка выявленная после ревью решения отнимает бал, задача выполненная без ошибок — добавляет бал. Ревью могут проводить сотрудники с теми же компетенциями и с ролью +- один шаг. Ревью с претензией к ошибке которая не подтвердилась отнимает бал у ревьювера. При наборе положительного порога балов происходит предложение с повышением роли. При падении рейтинга к отрицательному значению — роль понижается на одну ступень автоматически. При изменении роли рейтинг обнуляется. Вышестоящая роль может генерировать задачу, но не может её распределять. Задачи забирают сотрудники в зависимости от своих специализаций и приоритетов с ролями указанными в задаче. Сотрудник получает базовый оклад и оплату за успешно прошедшие ревью задание(я). Если нарушены сроки выполнения задачи, задача снимается с сотрудника и составляется рапорт в задаче о причинах, после чего задача отправляется на ревью. Сотрудник получив задачу, может не стартуя отправить её на ревью с указанием об ошибках или неточностях.
5. Утверждение сторонами бюджета этапа(ов) и сроков, подписание соглашения и старт работ после оплаты этапа.
6. После прохождения оплаты минимально достаточной для составления ТЗ заводится задача на архитектора. Получившийся документ подтверждает заказчик.
7. Документ спускается на одну роль вниз и запускается дальнейшая декомпозиция.
8. При необходимости изменения функционала заводится задача в корень проекта на архитектора. На каждом этапе в дерево проекта добавляется документ(или используется система знаний типа wiki) обосновывающий принятое решение и в дальнейшем дополняется.
Такой подход не требует фиксированного количества сотрудников, не требует от сотрудников выполнения задач для которых у них нет компетенций. Сотрудник может зарабатывать столько столько считает нужным. Переход и отношения между ролями максимально независимы и корректируются автоматически.
1. Требуется обязательное наличие сотрудника с ролью — архитектор/ведущий специалист по компетенции необходимой для решения задачи. Количество сотрудников будет влиять только на скорость достижения этапов решения. Желательно наличие системы постановки задач(jira), таймменеджмента, документооборота, система контроля версий(git).
2. Перед работой необходимо определиться с уровнями задач их стоимостью и сроками реализации. Например «архитекторская» — декомпозиция требований из ТЗ на блоки (передача данных, хранение, обработка и выдача, технологии, библиотеки), составление обоснования на решение задачи, задачи для исполнителей, сроки исполнения, время 14 рабочих дней, стоимость — 50 000 руб. «ведущий/сеньёр» — декомпозиция блока на модули, документ с обоснованием, постановка задач, сроки реализации.
3. Установить единные правила в работе с кодом(code convention), приоритет на подробное документирование и «чистый» код функций и классов. Приоритет простоте вместо сложных языковых конструкций.
4. Определение матрицы компетенций и роли доступных сотрудников и/или находящихся в резерве (удалёнщиков/фрилансеров). В системе постановке задач сотрудник должен видеть весь список задач по своим компетенциям и роли +- один шаг.
5. Принять концепцию рейтинга сотрудника — ошибка выявленная после ревью решения отнимает бал, задача выполненная без ошибок — добавляет бал. Ревью могут проводить сотрудники с теми же компетенциями и с ролью +- один шаг. Ревью с претензией к ошибке которая не подтвердилась отнимает бал у ревьювера. При наборе положительного порога балов происходит предложение с повышением роли. При падении рейтинга к отрицательному значению — роль понижается на одну ступень автоматически. При изменении роли рейтинг обнуляется. Вышестоящая роль может генерировать задачу, но не может её распределять. Задачи забирают сотрудники в зависимости от своих специализаций и приоритетов с ролями указанными в задаче. Сотрудник получает базовый оклад и оплату за успешно прошедшие ревью задание(я). Если нарушены сроки выполнения задачи, задача снимается с сотрудника и составляется рапорт в задаче о причинах, после чего задача отправляется на ревью. Сотрудник получив задачу, может не стартуя отправить её на ревью с указанием об ошибках или неточностях.
5. Утверждение сторонами бюджета этапа(ов) и сроков, подписание соглашения и старт работ после оплаты этапа.
6. После прохождения оплаты минимально достаточной для составления ТЗ заводится задача на архитектора. Получившийся документ подтверждает заказчик.
7. Документ спускается на одну роль вниз и запускается дальнейшая декомпозиция.
8. При необходимости изменения функционала заводится задача в корень проекта на архитектора. На каждом этапе в дерево проекта добавляется документ(или используется система знаний типа wiki) обосновывающий принятое решение и в дальнейшем дополняется.
Такой подход не требует фиксированного количества сотрудников, не требует от сотрудников выполнения задач для которых у них нет компетенций. Сотрудник может зарабатывать столько столько считает нужным. Переход и отношения между ролями максимально независимы и корректируются автоматически.
Спасибо! У Вас больше техника описана, а у меня про трансформацию подхода к управлению. Видимо, у Вас большой опыт реализации подобных систем.
Мои комментарии/вопросы по пунктам:
1. Руководитель группы, в любом случае должен быть. Его можно назвать ведущим, можно ответственным. Это человек, который знает работу лучше всех исполнителей, разрабатывает архитектуру и отвечает за качество.
2. Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
3. ++
4. В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
5. С рейтингами исполнителей на практике не работал. Обычно фиксируются только отклонения в плюс или минус и дальнейшее изменение роли по результатам аттестации. Дайте, если возможно, ссылку, или описание инструмента, в двух словах. Возможно, это то чего в моей системе не хватает, так как я работаю в рамках стандартных ролей и грейдов.
5. ++
6. Как быть если возможна только пост — оплата?
7. До какого уровня мы делали декомпозицию в пункте 2? Что если дальнейшая декомпозиция повлечет изменение стоимости?
Как я себе понял, описывается некая самоорганизующаяся команда, даже не SCRUM, а что то еще дальше, у которой на входе есть бек — лог задач, а на выходе результат в сроки, которые определяет команда. Типа биржы или круад — сорсинга. Кто в данном случае отвечает и определяет объем, сроки и приоритеты? На сколько такой подход применим в случае заказной разработки?
Инициатива с рейтингами очень интересная. Каждой атомарной задаче присваивается рейтинг. Фиксируется уровень исполнения задачи сотрудником. Ведутся правила присвоения следующей роли, на основании суммарного рейтинга (сумма нарастающим итогом, максимальное, минимальное, среднее). Такая система делает рост сотрудника максимально прозрачным и все повышения обоснованными. Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Мои комментарии/вопросы по пунктам:
1. Руководитель группы, в любом случае должен быть. Его можно назвать ведущим, можно ответственным. Это человек, который знает работу лучше всех исполнителей, разрабатывает архитектуру и отвечает за качество.
2. Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
3. ++
4. В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
5. С рейтингами исполнителей на практике не работал. Обычно фиксируются только отклонения в плюс или минус и дальнейшее изменение роли по результатам аттестации. Дайте, если возможно, ссылку, или описание инструмента, в двух словах. Возможно, это то чего в моей системе не хватает, так как я работаю в рамках стандартных ролей и грейдов.
5. ++
6. Как быть если возможна только пост — оплата?
7. До какого уровня мы делали декомпозицию в пункте 2? Что если дальнейшая декомпозиция повлечет изменение стоимости?
Как я себе понял, описывается некая самоорганизующаяся команда, даже не SCRUM, а что то еще дальше, у которой на входе есть бек — лог задач, а на выходе результат в сроки, которые определяет команда. Типа биржы или круад — сорсинга. Кто в данном случае отвечает и определяет объем, сроки и приоритеты? На сколько такой подход применим в случае заказной разработки?
Инициатива с рейтингами очень интересная. Каждой атомарной задаче присваивается рейтинг. Фиксируется уровень исполнения задачи сотрудником. Ведутся правила присвоения следующей роли, на основании суммарного рейтинга (сумма нарастающим итогом, максимальное, минимальное, среднее). Такая система делает рост сотрудника максимально прозрачным и все повышения обоснованными. Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
У Вас больше техника описана, а у меня про трансформацию подхода к управлению.
Это вольный пересказ части концепта внутреннего сервиса. Концепт был призван решить задачу по доступу в регионах к удалённым внешним специалистам. Вести биллинг по прогрессу проекта заказчика. Автоматизировать учёт и управление проектной документацией. По сути, в сложившейся обстановке экономического кризиса это и есть вариант взаимодействия с заказчиком и исполнителями в удалённом, автоматизированном режиме.
Руководитель группы, в любом случае должен быть. Его можно назвать ведущим, можно ответственным. Это человек, который знает работу лучше всех исполнителей, разрабатывает архитектуру и отвечает за качество.
Да, я написал об этом. Обязательно должен быть человек отвечающий за связи и чистоту сделок и технический специалист (до тех пор пока под ним не выстроится пирамида исполнителей).
Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
Для этого предусмотрена связь через ревью задачи снизу вверх, вышестоящая роль даёт сроки завершения усредняя время похожих типовых задач. В дальнейшем эти сроки могут входить в статистику для расчётов других задач в автоматизированном режиме.
В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
Если в подчинении 2 — 3 исполнителя, то можно и в рукопашную. Если их от 10 и более, вы утоните в рутине которая будет отнимать большую часть времени. Регулировка мотивации на задачи производится через назначение соответствующей стоимости задачи или директивно штатным сотрудникам.
С рейтингами исполнителей на практике не работал. Обычно фиксируются только отклонения в плюс или минус и дальнейшее изменение роли по результатам аттестации. Дайте, если возможно, ссылку, или описание инструмента, в двух словах. Возможно, это то чего в моей системе не хватает, так как я работаю в рамках стандартных ролей и грейдов.
Есть более простой вариант. Исполнитель заводит аккаунт в сервисе тестирования, выбирает навыки и набирает баллы. Результат через API сервиса заводится в систему. Параметры заполняют матрицу компетенций сотрудника и ему открываются задачи в соответствии с его ролью +- один шаг. Он может ревьювить готовые задачи или выполнять лежащие в стеке(эпике). Документ предоставить не могу, это концепт который не пошёл в разработку, но принадлежащий компании.
Как быть если возможна только пост — оплата?
Разбить бюджет на этапы и предоплачивать. Это прямой аналог абонплаты, работы ведутся и деньги прозрачно списываются. Начинаются по факту оплаты достаточной для входа в рут проектного дерева к архитектору. Заканчиваются при недостаточности средств на счету и возобновляются при пополнении. Заказчик может в любой момент выйти и забрать из git наработки, законсервировать в сервисе (за отдельную плату) и т.д. вообщем крайне гибко.
До какого уровня мы делали декомпозицию в пункте 2? Что если дальнейшая декомпозиция повлечет изменение стоимости?
Декомпозиция ведётся до класса или функции в мере достаточной для выполнения последней(исполнительной) ролью в дереве когда уже ясны сроки и стоимости. вышестоящие роли могут брать задачи нижестоящих чтоб не терять квалификацию :)
Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Вопрос не в руководителях, а в самой возможности вести бизнес в регионах с острым кадровым голодом.
Спасибо!
Прекрасная система. Особенно мне понравилось про рейтинги.
(Еще пара вопросов/комментариев по тексту в скобках.)
Крайнее важно, чтобы в оценке принимали участие исполнители, которые потом будут это делать. В противном случае имеем риск снижения вовлеченности и ответственности за результат.
Для этого предусмотрена связь через ревью задачи снизу вверх, вышестоящая роль даёт сроки завершения усредняя время похожих типовых задач. В дальнейшем эти сроки могут входить в статистику для расчётов других задач в автоматизированном режиме.
(Ревью снизу вверх делается до начала работы над задачей или после завершения задачи? Проще говоря, может ли исполнитель оспорить срок до начала работы, чтобы потом не оказаться причиной превышения сроков?)
В моем понимании, распределять задачи должен руководитель, исходя из уровня загрузки. Иначе все будут брать только простые или интересные задачи, а у нас есть еще и нужные. Кто определяет приоритеты?
Если в подчинении 2 — 3 исполнителя, то можно и в рукопашную. Если их от 10 и более, вы утоните в рутине которая будет отнимать большую часть времени. Регулировка мотивации на задачи производится через назначение соответствующей стоимости задачи или директивно штатным сотрудникам.
(В моем понимании, руководитель, все равно, должен определять приоритеты — что надо сделать обязательно и в первую очередь, а что можно потом. Например, вначале делаем базовый функционал а потом экранные формы и отчеты. В противном случае, мы получаем один из трех вариантов — сделано все, кроме того что нужно или мы вынуждены переплачивать за базовый функционал, чтобы его хотя бы кто — то взялся делать или его специально не делают, чтобы поднять цену, а потом сделать.)
Но, она будет не выгодна руководителям, практикующим манипулятивный менеджмент.
Вопрос не в руководителях, а в самой возможности вести бизнес в регионах с острым кадровым голодом.
(Я имел в виду, когда повышение сотрудников ведется на основе личных отношений, а не объективных факторов. Или когда субъективные факторы используются для отказа в повышении. При наличии и использовании рейтингов такая история затруднительна.)
(Ревью снизу вверх делается до начала работы над задачей или после завершения задачи? Проще говоря, может ли исполнитель оспорить срок до начала работы, чтобы потом не оказаться причиной превышения сроков?)
Если нарушены сроки выполнения задачи, задача снимается с сотрудника и составляется рапорт в задаче о причинах, после чего задача отправляется на ревью. Сотрудник получив задачу, может не стартуя отправить её на ревью с указанием об ошибках или неточностях.
Специалист без сомнения лучше владеет информацией по параметрам выполняемой задачи, так как специализируется на ней(допустим). Но если исполнителем сроки или стоимости указаны не совпадающие с расчётными, это достаточно просто выявить сравнив(в автоматическом режиме) такие же параметры у других исполнителей с похожими ролями и задачами. К тому же всегда остаётся вероятность неверной оценки трудоёмкости задачи и у исполнителя есть инструменты для корректировок в рапорте дать оценку которому могут ревьюверы.
(В моем понимании, руководитель, все равно, должен определять приоритеты — что надо сделать обязательно и в первую очередь, а что можно потом. Например, вначале делаем базовый функционал а потом экранные формы и отчеты. В противном случае, мы получаем один из трех вариантов — сделано все, кроме того что нужно или мы вынуждены переплачивать за базовый функционал, чтобы его хотя бы кто — то взялся делать или его специально не делают, чтобы поднять цену, а потом сделать.)
Для этого у задач есть приоритеты и стоимости. Если задача настолько сложна, что за неё не берутся, это повод для пересмотра уровня декомпозиции. Если слишком проста или рутинна — повод пересмотреть стоимость. Ситуации, когда может возникнуть демпинг со стороны исполнителя возможна при отсутствии конкуренции и недостаточности количества исполнителей. При заполнении дерева исполнителями, таких ситуаций должно быть единицы и по каждому стоит разобраться отдельно и внести в систему коррективы. Решением может быть — ядро сотрудников на окладе но в системе, в таком случае задачу можно поставить директивно непосредственно исполнителю. Либо выделить специальную роль «пожарная команда» у которой в обязанности по договору входит брать в работу задачу с максимальным приоритетом. Уведомление о добавлении задачи реализуется с помощью сторонних инструментов вроде слак или почты. Почему выбран стек задач и свободный выбор? Это задумано для максимальной специализации исполнителя. Специализация по конкретной узкой области даёт максимальную скорость выполнения. Когда узкий специалист в штате — это невыгодно так как специализированные задачи в среднем не превышают 5% от общей численности. Для специалиста это тоже выгодно, он может заниматься только тем что ему нравиться и что у него лучше получается, при этом он может брать задачи из N проектов и не простаивать.
(Я имел в виду, когда повышение сотрудников ведется на основе личных отношений, а не объективных факторов. Или когда субъективные факторы используются для отказа в повышении. При наличии и использовании рейтингов такая история затруднительна.)
В конкурентной борьбе такие сообщества обречены, их существование вопрос времени, а экономический кризис выступит в роли катализатора. Делать ставку на модели ведения бизнеса обречённые с «эволюционной» точки зрения я бы не стал. Это возможно в «распильных» фирмах при чиновниках и продолжаться может до завершения бюджетного финансирования, но в частном бизнесе — это путь к краху. Себя хорошо показала китайская модель экономической системы, смесь из коммунистических и капиталистических методов. В описанной выше модели, гарантированы личные свободы, права защищены невозможностью прямой связи между ролями и отрицательной обратной связью по качеству выполняемых задач.
Аналитика по удаленной работе. Правда на английском:
medium.com/@ezelby/remote-work-market-map-58591966b0c2
medium.com/@ezelby/remote-work-market-map-58591966b0c2
Sign up to leave a comment.
Новые вызовы для руководителей в условиях удаленной работы