Русский
Русский
English
Статистика
Реклама

Управление временем

DevOps или как мы теряем заработную плату и будущее IT-отрасли

16.07.2020 18:14:38 | Автор: admin
Самое печальное в сегодняшней ситуации то, что IT постепенно становится отраслью, где вообще нет слова стоп в количестве обязанностей на 1 человека.

Читая вакансии иногда уже даже видишь не 2-3 человека, а целую компанию в 1 лице, все спешат, тех.долг растёт, старое legacy на фоне новых продуктов выглядит совершенством, потому что в нём хотя бы есть дока и комменты в коде, новые продукты пишутся со скоростью света, но в итоге пользоваться ими нельзя ещё год после их написания, и зачастую этот год прибыли не приносит, более того, расходы на облако выше, чем продажи сервиса. Деньги инвесторов уходят на содержание ещё не работающего сервиса, но который уже выпустили в сеть как рабочий.
Как пример: известная компания, чей ремастер старой игры получил самые низкие оценки за всю историю индустрии. Я был одним из тех, кто купил данный продукт, но даже сейчас этот продукт работает ужасно, и по идее ещё не должен был в таком виде выходить в продажи. Возвраты денег, падение рейтинга, огромное количество банов пользователей на форумах за жалобы на работу сервисов. Количество патчей не восхищает, а ужасает, но всё равно продукт не юзабелен. Если этот подход приводит к таким результатам у компании, которая занимается разработкой с 91 года, то у компаний, которые только начинают свою деятельность, ситуация ещё хуже.

Но это мы посмотрели на результаты такого подхода со стороны пользователя сервиса, а теперь посмотрим на проблемы, которые возникли у сотрудников.

Я часто слышу утверждение, что DevOps команд не должно быть, что это методология и т.д., но вот беда, компании почему-то перестали искать ноков, dba, инфруктурщиков и build инженеров сейчас это всё DevOps инженер в единственном лице. Конечно, в отдельно взятых компаниях такие вакансии ещё есть, но их всё меньше. Многие это назвали развитием, я лично в этом вижу деградацию, невозможно поддерживать по всем направлениям хороший уровень знаний, и при этом успевать работать не более 8 часов. Естественно это фантазии. В реальности, многие ITшники вынуждены работать и по 12, и по 14 часов, из которых оплачивается 8. А зачастую и без выходных, потому что мне поставили задачу, доков нет или кривые, да ещё и денег стоит сервис, а за 1 ошибку в облаке можно в принципе не получить з\п за пару месяцев, особенно, если работаешь по ИП. Мы по факту теряем слово в бизнесе, вместе с разделением обязанностей, я всё чаще сталкиваюсь с тем, что менеджеры лезут в процессы разработки, вообще в них ничего не понимая, они путают бизнес-данные и работу приложения, в результате начинается хаос.

Когда начинается хаос, бизнес хочет найти виновного, и тут нужно универсального виновного, повесить вину на 10+ человек сложно, поэтому менеджеры объединяют позиции, ведь чем больше обязанностей у 1 специалиста, тем проще доказать его халатность. А в условиях Agile нахождение виновного и порка это основа данный методологии ведения бизнеса в менеджменте. Agile давно вышел из IT, и основной его концепции стало требование ежедневных результатов. Проблема в том, что у узкоспециализированного специалиста не всегда будет ежедневный результат, а значит отчитаться будет сложнее, и это ещё одна причина, почему бизнес хочет специалистов по всему. Но основная причина конечно же, это ФОТ он основная причина всех изменений, ради надбавки люди соглашались работать за себя и того парня. Но в итоге, как и в других сферах, это просто стало теперь обязанностью, за меньшую оплату большего кол-ва предоставленных услуг.

Сейчас можно часто увидеть даже статьи о том, что уже и разработчики должны уметь деплоить, должны заниматься инфраструктурой рядом с DevOps инженером, но к чему это приводит? Правильно к падению качества сервисов, к падению качества разработчиков. Вот буквально 2 дня назад я объяснял разработчику, что писать и читать можно из разных хостов, а мне с пеной у рта доказывали, что никогда такого не видели, вот есть в settings orm host, port, db, user, password и всё. Зато разработчик умеет запускать деплои, писать ямлы. Но уже забывает про юнит тесты и комменты в коде.

По итогу мы видим следующее постоянные переработки, поиски решений проблем вне рабочего времени, постоянное обучение в выходные, и не для роста доходов, а для поддержки себя на плаву. Разработчики вынуждены помогать DevOps инженеру с CI/CD, а если у разработчика нет времени, тот начинает зашиваться, и менеджеры начинают компостировать мозги, а, если это не помогает увеличить желание работать сверхурочно, то применять взыскания и штрафы, человек ищет новое место работы, оставляя после себя тех.долг размером с Эверест, в результате долг начинает расти и у разработчиков, т.к. они вынуждены писать код с меньшим его рефакторингом, чтобы успеть помочь либо старому или новому DevOps инженеру, а менеджеров всё вполне устраивает, ведь виновный есть и его видно сразу, а значит основное правило при Agile в менеджменте соблюдено, виновный найден, результаты по его порке видны.

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

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

Перевод Нет Jira нет проблемы

11.04.2021 12:12:58 | Автор: admin

Для тех везунчиков, которые пока не имели дела с Jira (если тут такие есть), сообщаю: Jira это инструмент для управления проектами, и на первый взгляд всё в этой системе выглядит весьма солидно и пристойно.

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


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

Но вот что примечательно: Jira преподносит себя как "рабочий инструмент номер один для гибких команд". Гибких? Хм-мм... Если для управления Jira нужен особый человек или даже целая аутсорсинговая компания, о какой гибкости можно говорить?

Давайте разберёмся, что вообще означает термин "гибкий" (Agile) и почему про него все сегодня говорят?

Последовательная разработка

Сегодня только и разговоров, что про методику Agile, как раньше про методику Waterfall. Впервые каскадная методика Waterfall была описана Уинстоном Ройсом в статье, опубликованной в 1970 году. Хотя термин Waterfall (каскад) не был употреблён в статье ни разу, описание метода напомнило многим каскадную схему:

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

Основная идея методики: любое планирование процессов разработки программного обеспечения должно осуществляться заранее, после чего должны выполняться последовательные шаги по созданию и поставке программного обеспечения. Данная концепция отлично вписывается в старые идеи научных методов управления, заложенные Фредериком Уинслоу Тейлором ещё в 1911 году. Если опустить детали, его идея состоит в следующем: организацию работ нельзя доверять исполнителям, нужна отдельная группа людей группа организаторов процесса, которая разработает последовательность действий, после чего безукоснительное выполнение таких действий поручается исполнителям.

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

Встреча в Сноубэрд

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

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

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

Изменение требований на поздних этапах является конкурентным преимуществом

-Мэри Поппендик

Группа Сноубэрд выработала определённые ценности и принципы, получившие известность как Манифест гибкой разработки программного обеспечения.

Основные положения манифеста:

  • Люди и взаимодействие важнее процессов и инструментов.

  • Работающий продукт важнее исчерпывающей документации.

  • Сотрудничество с заказчиком важнее согласования условий контракта.

  • Готовность к изменениям важнее следования первоначальному плану.

В Манифесте ничего не говорится о том, что слова справа имеют меньшее значение, а слова слева большее. Такой образ мыслей был вдохновлён моделью Бережливого производства, основным принципом которой было постоянное стремление предприятия к устранению любых видов потерь. Всё, что не добавляет ценность для потребителя, считается потерями. Зачастую слова справа могут быть связаны именно с потерями.

Что произошло?

Если первым (основным) принципом манифеста является "Люди и взаимодействие важнее процессов и инструментов", то почему все гибкие команды, в которых мне (или вам) приходилось работать, так высоко ценят процессы и инструменты? И тут я опять поминаю недобрым словом Jira. Не дай бог составить задачу вразрез с требованиями Jira, не дай бог добавить хоть одну строку кода без разрешения Jira...

Корень зла, согласно прагматическому замечанию Дэйва Томаса, кроется в том, что слово agile прилагательное, превратилось в Agile (собственное) существительное. Существительные продаются лучше, чем прилагательные, и даже возник "Промышленный комплекс Agile", приторговывающий маркой "Agile".

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

Если идея гибкости возникла в результате признания того факта, что мы не можем предвидеть, как именно могут измениться требования, то единого решения (процесса), которое подошло бы для всех возможных сред, не может быть просто по определению. "Agile-эксперты" навязывают нам определённый процесс, и такое состояние Мартин Фаулер называет неприкрытой пародией на "гибкость".

Как же так, вообще без процесса?

Но нужен же какой-то процесс, разве нет? Нужен, но какой? Да очень простой использовать всё, что работает! Но как узнать, будет ли он работать? Тут следует применить эвристический подход.

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

Инструменты

А что с инструментами? Да то же самое, что и с процессом используйте всё, что работает. Или, если говорить точнее, используйте любой инструмент, который лучше всего подходит для процесса. Но будьте осторожны. Поскольку ваш процесс, скорее всего, изменится, гибкость такого инструмента должна быть достаточно высока, чтобы подстроиться под такие изменения. Также не следует делать ставку на какой-либо конкретный инструмент, ведь рано или поздно придётся переключиться на другой инструмент, лучше подходящий для (изменённого) процесса.

Инструмент, подходящий под это описание и имеющийся в каждом офисе, уже имеется!

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

Что не так с Jira?

Если не вдаваться в детали, Jira не нравится мне тем, что она навязывает пользователю определённый процесс. Но этим дело не ограничивается. Я даже был свидетелем того, как команды разработчиков были вынуждены подстраивать свои процессы под Jira, что является грубым нарушением принципа "Люди и взаимодействие важнее процессов и инструментов".

Неприязнь к Jira у меня накопилась потому, что именно от общения с этим инструментом у меня больше всего разбаливается голова, однако не лучше обстоят дела с другими специализированными инструментами управления программным обеспечением. Если конкретный используемый вами инструмент не подходит (в каком-то смысле) к вашему процессу, как долго вы будете пытаться побороть инструмент, прежде чем плюнуть и настроить процесс под требования инструмента?

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

Между прочим, Atlassian (компания-разработчик Jira) постоянно ищет себе инженеров по различным направлениям, в числе прочих нужны Fullstack-разработчики и Java-разработчики. Если одна из ваших целей релоцироваться в компанию с мировым именем, то приходите учиться, прокачаем ваши скилы и поможем выгодно представить их в резюме.

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Из песочницы Как оцифровать разработчика или коротко о том, как сделать работу разработчиков более прозрачной для Компании

19.09.2020 22:22:49 | Автор: admin

Преамбула


В одном, среднем по размеру российском Банке, есть интернет банк для физиков и юриков, сайты и мобильные приложения. А также есть подразделение, которое все это хозяйство сопровождает и развивает. Сюда и приходит молодой Руководитель, проработавший в этой организации уже более 3 лет, от лица которого и будет данное повествование.


Предыстория


Банк современный, процессы построены согласно ITIL, на первый взгляд все выглядит по учебнику. Как видно из названия статьи, мы затронем только один кусочек из интересующего нас процесса Внесения изменений.


Проблема


Все в этом процессе было отлично за исключением одного момента, а именно согласования Аналитиком сроков разработки с Заказчиком владельцем продукта Интернет банк юридических лиц, каналы web+mobile, далее будем называть его просто Заказчиком. Заказчик всегда понимал и принимал работы, которые проходили у него на глазах или с его участием, а именно:


  • Уточнение и формализация его требований. Он непосредственно видел, как из его 2-х строчек текста рождается клиентская история, прототип, и наконец, постановка для разработчика.
  • Все виды тестирования. Он видел огромные списки тестов.
  • Документирование. Он мог посмотреть на количество страниц текста и картинок(схем).
  • А вот в части разработки заказчик всегда чувствовал подвох, ему казалось, что злобный(а на самом деле добрейшей души человек) бородатый тимлид, давший свою оценку, только и видит, как вписать туда процентов 50 лишних часов, не утруждаясь уложиться в SL и получить мотивацию по KPI. Эту проблему и пришлось решать молодому Руководителю.

Решение


Шаг 1. Как в абсолютных значениях рассчитать длительность разработки

Идей было много, одна из них: делать оценку на основании ранее выполненных задач, лучше, чем ничего, но:

  • трудоемко делать каждый раз ретроспективный анализ
  • далеко не для всех задач можно подобрать аналоги.

Что, если не брать задачи целиком, а каждую разделить на конечные составляющие работ для нашей системы(системой, на протяжении всей статьи, будем называть Интернет банк юридических лиц, каналы web+mobile)?

В нашем случае получилось так:

  1. Изменение верстки страницы
  2. Создание новой документарной страницы
  3. Доработка формы, вывод нового поля формы из БД
  4. Типовой контроль
  5. Сложный контроль (сложный нетривиальный алгоритм)
  6. Расширение схемы БД
  7. Скрипт СМС рассылки
  8. Скрипт для рассылки по ЭП

и т.д. в начале позиций было порядка 20, а в результате чуть больше 80

Для оценки трудоемкости каждого блока была придумана единица стандартная единица трудозатрат(СЕТ, s). СЕТ это абстрактная мера измерения трудоемкости, она не имеет под собой физического смысла, можно назвать как угодно. Путем ретроспективного анализа(за последние 3 месяца), мы(я, аналитик по системе и тимлид) разбили все задачи на конечные составляющие и пропорционально оценили трудоемкость каждой из них(si), результат в таблице(табл.1).



Теперь каждую задачу мы могли оценить в СЕТах, например:

  1. Задача: реализовать форму обратной связи на главной странице системы, которая появляется у клиентов, не давших обратной связи. На форме отображены:
    • шкала оценки в форме звездочек, кликом по которым можно дать оценку от 1 до 5,
    • поле ввода в свободной форме длиной 500 символов,
    • кнопка отправить, по нажатию на которую осуществляется запись данных в соответствующую таблицу БД, закрытие формы без перезагрузки страницы.
  2. Детерминация на простейшие действия, согласно табл.1.:
    • Создание таблицы в существующей БД, написание логики отображения формы 0,2 СЕТ
    • Верстка формы, 2 поля + проверка на заполненность 1 СЕТ
    • Написание асинхронного запроса к серверной части, написание серверной функции записи в БД, 1 СЕТ
  3. Расчет трудоемкости в СЕТах: 1+1+0,2=2,2 СЕТ

После этого, был введен термин производительность(p), который определяет производительность каждой категории разработчика(Табл.2)



Теперь стало возможным оценить длительность разработки каждой задачи по формуле:



продолжим на нашем примере

4. Определение длительности работ, для сотрудника категории Senior:
2,2(СЕТ)/1,5(СЕТ/день)=1,6 дней
Длительность 1,6 дней


Принимаем допущения: имея full-stack разработчиков, на решение каждой отдельной задачи привлекается только один из них.

Методика оценки так понравилась Заказчику, что он предложил оценивать остальные этапы работ:

  • уточнение требований
  • планирование реализации
  • тестирование и документирование

в пропорциональном отношении от времени разработки, так были введены следующие коэффициенты (Табл. 3):



Теперь была возможность оценить длительность каждого этапа:



всю длительность внесения изменений в систему, по формуле:



например:

4. Определение длительности работ, для сотрудника (аналитик и разработчик) категории Senior:

0,2*2,2/1,5+0,3*2,2/1,5+2,2/1,5+0,2*2,2/1,5=0,3+0,44+1,6+0,3=2,64 дня
Длительность 2,64 дня



В результате получилась достаточно понятная методика, общим собранием (Заказчик, я, аналитик по системе и тимлид) решили ее опробовать, о первых результатах будет в продолжении
Подробнее..

8 последствий переработок руководителя

09.06.2021 12:21:23 | Автор: admin
image

Как вы охарактеризуете руководителя, который работает не 8-9 часов, а 11-12? Это хорошо и можно его назвать вовлеченным, или есть нюансы?

Надеюсь перед ответом на эти вопросы вы немного задумались и не спешили отвечать. На самом деле, действительно есть нюансы и нет единого правильного ответа.

Основным аргументом в причине переработок является желание сделать больше. Если это получается, это несомненный плюс. Но, предлагаю также рассмотреть и минуса, на которые редко обращают внимание

________________________________________________

Возможные последствия переработок руководителя:



1. Усталость и выгорание



Логичным следствием регулярных переработок является усталость. И, не столько физическая, сколько моральная и умственная. Когда руководитель работает по 12-14 часов, его мозг устает, и на следующий день долго запускается и в течении дня сильно тормозит. От чего руководитель может: упускать важные детали, принимать не оптимальные решения, допускать ошибки, говорить глупости, резко реагировать на ошибки сотрудников, .

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

2. Лишние расходы компании



Я говорю не только про сверхурочные, которые компания должна заплатить. Давайте посмотрим еще с другой стороны. Переработки руководителя часто связаны с выполнением им непрофильной работы, которая имеет меньшие квалификационные требования. Попросту говоря, руководитель делает то, что легко может выполнить кто-то менее квалифицированный и важный. Соответственно, такая работа стоит дешевле. И, так как, в большинстве компаний нет градации и тарификации в зависимости от работ, и компании приходится платить за часы выполнения этой работы по прайсу часов руководителя.

Чтобы было проще понять, разберем на примере:

Вводные

Задание: посчитать, сколько осталось в наличии винтовых гвоздей.
Ориентировочная продолжительность выполнения: 4 часа
Тариф руководителя: 10$/час
Тариф сотрудника: 5$/час

Моделируем ситуацию

Руководителю приходит такое задание. Он, глянув на своих сотрудников и на их серьезный вид, делает вывод, что все заняты, и решает взять это задание на себя. Плюс ко всему, он уверен, что никто лучше него с этим не справится и он сможет сделать его быстрее и качественнее. На выходе так и получается: руководитель выполняет задание за 3 часа (на час быстрее). Но, действительно ли это победа для компании? Подобьем итоги:

  • задание выполнено быстрее и обошлось в 30$. При этом, даже, если бы оно было выполнено за 4 часа, оно было-бы дешевле 20$. Даже, если бы за 5 часов это было бы 25$, что, также, дешевле;
  • компания сэкономила 3 часа работы штатного сотрудника, при этом потеряла 3 часа работы руководителя (более квалифицированного и более важного).


Не утверждаю, что подобная математика это всегда правильно. Иногда выгоднее потратить время руководителя, чем время сотрудника. Особенно, если сотрудник работает над уникальным проектом, его нельзя отрывать и его никто заменить не может. Но, всегда ли это так?

3. Не успевает выполнять свои обязанности, которые более сложны



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

Часто такой работой становится именно управленческая функция: планирование, делегирование, контроль,. Руководитель не успевает проводить анализ достижения целей подразделения, руководитель не успевает вырабатывать решения по нейтрализации отклонений, руководитель не успевает проводить профилактические мероприятия для недопущения отклонений. Сотрудники такого руководителя недосмотрены, недохвалены, недообучены. Ему некогда!

Как понимаете это замкнутый круг: чем больше руководитель работает руками -> тем меньше у него времени на то, чтобы обучить этой работе кого-то -> тем больше ему приходится выполнять работ самостоятельно

Поэтому, руководителю приходится растягивать свой рабочий день еще на несколько часов, так как он просто не успеет все сделать.

4. Разрешение быть непрофессиональным



Переработки позволяют руководителю избегать развития и практики управления. Ему не нужно учится делегировать, не нужно учиться контролировать. Зачем ему кого-то принуждать и становится плохим человеком? Можно поработать больше и сделать все самому.

Кроме того, есть же правило: хочешь сделать хорошо сделай это сам. Это еще один аргумент, почему не стоит кому-то поручать.

5. Разрешение быть неэффективным



Переработки позволяют руководителю не думать об эффективности и планирование своего рабочего дня. Когда твой рабочий график не нормированный, можно не париться над тем, чтобы оптимально тратить время в течении дня: можно не готовится к совещаниям (подготовка бы сократила длительность), можно посмотреть видосики в течении дня, можно пойти долго попить кофе, можно принимать всех приходящих к тебе и всем говорить да. К чему себя ужимать и куда-то спешить, если можно растянуть рабочий день до 10-12 часов и спокойно все сделать?

6. Балованная структура



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

Сотрудники привыкают к полурасслабленному режиму, и потом, когда поменяется власть, либо в голове у руководителя произойдут изменения, такую структуру будет сложно расшевелить (без последствий).

7. Демотивация



Среднестатистический руководитель более квалифицированный, чем среднестатистический сотрудник. Он это понимает, и для него это один из важных фильтров. И, когда такому руководителю приходится выполнять работу, которая не требует всех его знаний, навыков и опыта (менее квалифицированную), она его, мягко говоря, не радует.

Когда это временная акция это терпимо. Если же это постоянная необходимость это может быть сильным фактором демотивации.

8. Игнорирование человеческого потенциала



Когда руководитель имеет в своем арсенале инструмент возможность переработать, он становится менее проактивным и меньше обращает внимание на потенциал сотрудников.

Так, если руководитель не может задерживаться, он всячески будет стараться находить внутри структуры возможности. Он изучит своих сотрудников, он их будет развивать, он будет использовать их потенциал на 100%. Все для того, чтобы успеть вовремя. Его это мотивирует, чтобы находить возможности!
________________________________________________

Выводы:



1) Если ваш подчиненный руководитель и он перерабатывает разберитесь, с чем это связано.

Я выделяю три популярные причины:

  • личное желание руководителя;
  • производственная необходимость;
  • так принято.


Самая страшная причина так принято. Она означает, что в компании существует негласное правило: кто много работает тот молодец. Угадайте кто виноват в существовании такого правила?:)

Остальные две причины более адекватные и требуют глубокого анализа. Если это личное желание это похвально, но стоит побеспокоится о том, чтобы это не влияло на структуру (проблемы 6 и 8). Если это производственная необходимость стоит ее проанализировать и понять, действительно ли переработка это единственный и правильный вариант.

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

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

Общий вывод:


Переработки это не плохо и не хорошо. Факт переработок просто показывает время, которое сотрудник тратит на выполнение своих функций и никак не может являться показателем его эффективности. Мы не должны ориентироваться на стереотипы перерабатывает значит молодец и вовлеченный или в 18:00 его уже нет значит ему пофиг на компанию. Нет! Увы, все намного сложнее и в каждом отдельном случае стоит покопаться в деталях. Что вам и советую регулярно делать!

Другие кейсы находите в telegram-канале: t.me/OS_management
Подписывайтесь! Далее будет
Подробнее..

Метод Любищева и учет времени по мотивам книги Даниила Гранина Эта странная жизнь

23.11.2020 12:04:01 | Автор: admin

Каждый из нас хотя бы раз в жизни задумывался о времени, его неумолимости и быстротечности.Вроде бы вчера ты окончил школу и поступил в университет, а уже сегодня тебе 36 лет, ты женат и у тебя двое детей, а по ощущениям тапропасть времени, которая прошла, слилась в один миг. Все очень стремительноНе так давно, в наше не простое время я был на онлайн-конференции слушателем и один из спикеров, известный предприниматель и основатель крупной ИТ-фирмы с множеством филиалов по всей России, говорил о своем личном и рабочем времени. Все как у всех:времени мало, то, что есть трудно распределить между важным и важным, плюс семья, одно накладывается на другое и в результате нет ни на что времени. Конференция была онлайн, докладчик был дома, выступая в череде таких же докладчиков, доклады которых слились в одно и слушались мною фоном.Но этот харизматичный человек как-то по-домашнему все рассказывал,даже показал нам свою собаку-пекинеса (чтобы вы понимали про атмосферу доклада). Столь необычная подача материала естественно приковала к себе мое внимание, и я начал внимательно его слушать. Речь была о книге Даниила Гранина "Эта странная жизнь" и методе Любищева, который практиковал автор доклада. Докладчик честно сказал, что эта вторая его попытка использовать этот метод в своей работе и личной жизни. На самом деле не понятно на сколько его хватит (намеренно не рассказываю о сути, т.к. позже постараюсь сделать это сам). А в конце доклада был совет прочесть эту книгу

В результате всего этого безобразия, я прочел книгу, впечатлился и появился блок учета времени по методу Любищева в мобильном приложении.

Про книгу "Эта странная жизнь" Даниила Гранина

Мне стало интересно, и я ее прочел. Странное ощущение от ее чтения, скажу откровенно. Как будто сел ты на лавочку в парке, а на ней уже сидит пожилой человек (Гранин). Он начинает с тобой говорить и в какой-то момент ты уже сам не понимаешь, как так получилось, что ты очень внимательно его слушаешь и ловишь каждое слово. Это совсем не похоже на книжный рассказ, больше на настоящий монолог. А рассказывает он о своем знакомом - профессоре Любищеве Александре Александровиче, который занимался наукой и добился в своей научной работе огромных результатов. Причем не только в энтомологии (раздел зоологии, изучающий насекомых), основной своей специальности, но и куче других наук: философии, зоологии, генетике, истории науки, математике. Был достаточно уважаемым в абсолютно разных кругах ученным. Когда Гранин рассказывал про профессора, у меняскладывалось впечатление, что он очень сильно переживал. Причем в самом начале я не совсем понимал причину почему, столь умудренный годами старик так переживает свой рассказ, но чем больше он говорил, тем больше становилось понятно, что он проецировал жизнь своего товарища по науке на себя. Его серьезно что-то беспокоило Любищев был примером для Гранина и Гранин, глядя на то, как организовал свою научную и личную жизнь его знакомый, как мне показалось, корил себя. Корил за то, что в отличииот своего коллеги, он не знает сколько он читает книг, как с годами меняется его работоспособность, как много он проводит времени с семьей и т.д. Это был разбор и переосмысление подхода одного умного человека к работе и жизни как жил другой выдающийся человек. Любищев был олицетворением устремленности. Например, Любищев, будучи энтомологом классифицировал блошек и, в то время как он шел на работу, ловил этих блошек на улице. Его коллекция этих блошек была больше, чем в музеях того времени. При всем при этом он не тратил на это свое рабочее время! Фи Скажет читатель. "Так что в этом выдающегося?".Мужик собирал блох, по дороге на работу. Это не достижение

На самом деле это пример того, о чем мы бы и не подумали бы никогда. Человек не тратил на коллекционирование своего РАБОЧЕГО времени, но имел сумасшедшую коллекцию.

А как вам следующийпример? Любищеввыучил в дороге в "отбросах времени" английский язык. Скажи читатель: ты каждый рабочий день едешь в метро, ты выучил хоть что-нибудь? :) А ведь то время, которое ты едешь и ничем не занимаешь это же минус время из твоей жизни. А время, как известно, это самый ценный и не восстановимый ресурс. Вчера вернуть будет уже нельзя.

Конечно, ты не исключишь эти "отбросывремени" из своей жизни. Дорога на работу, очередив больнице, какие-то ожидания и все подобное, ты все равно потеряешь на это время.Так почему же не наполнить его чем-то полезным? Мне кажется это очень здравая идея. Это один из примеров грамотного тайм менеджмента. Но это самая малость. Давайте перейдем к серьезным вещам.

Про Любищева и его систему

Начал вести Любищев свою систему с 26 лет и работал так до конца своих дней. Человек поставил цель всей своей жизни и шел к ней, не теряя эту цель. Суть же метода достаточно проста и сводилась к тому, что он фиксировал ВСЕ свое время как личное, так и любое другое со всей скрупулёзностьюи тщательностью, стараясь не тратить на учет много времени. Потом анализируясвои трудозатраты,мог точно сказать:

  1. Насколько хорошо он отработал в этот период по сравнению с прошлым периодом?

  2. Как многое из того, что он запланировал он выполнил и на сколько он продвинулся в этом?

  3. Сколькоон написал статей, рукописей, прочел книг, посетил выставок и т.д.?

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

Приведу очень хороший пример из нашей жизни.Навернякалюбой из вассталкивался с ситуацией, когда открываешь Ютубчик в обед в выходной день, начинаешь смотреть ролик, а потом еще, а потом еще Иглядь, через достаточно небольшой промежуток времени, а прошло уже часов 6 (!) При этом лично для вас время пролетело очень быстро. Любищев рассматривал время как что-то осязаемое и старался исключитьвот такие "быстрые" временные промежутки. Этого позволяет добиться как раз фиксирование времени, а фиксация порождает осознанность.

Ежедневный записи фиксировались с погрешностью в 10 минут, максимально коротко сокращались.Затем в конце месяца они группировались в месячные отчеты, месячные отчета анализировались и корректировались планы. Далее уже месячным отчеты трансформировались в годовые отчеты, а уже годовые отчеты сдавались и подводили итоги года. Причем сдача была перед самим собой и рассматривалась весьма категорически. Проводился анализ, где и как было упущено время, почему так произошло и как этого не допустить в будущем. Рассматривались причины, которые влияют на работоспособность. Например, его вторая жена и жизнь с ней были настолько хороши по-домашнему, что это сказывалось на его производительности. Весьма неожиданные выводы.

Через время появлялась статистика и можно было строить уже долго идущие планы вперед на основании потребления времени в прошлом.

Про целесообразность

Наверное, вы, как и я задались простыми вопросами: зачем мне это надо? Писать, что-то постоянно фиксировать и не забывать это фиксировать. Гранин уверен, что это просто необходимо. Возьмем для примера руководителя проектов (РП) или тимлида, хотя тут можно взять, наверное, любогои подобрать свои вопросы.

  1. А сколько времени ты потратил за последний год на свое обучение?

  2. Сколько рабочего времени ты тратишь не на профильные задачи?

  3. И наоборот, сколько тратишь личного времени на рабочие вопросы?

  4. Имеешь ли глобальную цель как руководитель проектов и на сколько далеко продвинулся в ее выполнении за последний год? А если этой цели нет, то, чего вообще хочешь от своей профессии?

Проблема в том, что ты этого не знаешь и вряд ли об этом даже задумывался Зачем вроде как это все тебе нужно? Я во всяком случае точно не задумывался.

А теперь возьмем твою личную жизнь.

  1. Ты много работаешь, как часто в этом году ты проводил время с женой? С детьми?

  2. Есть хобби? Если оно есть, много посвятил ему времени за последний год?

  3. Как часто виделся со своими друзьями в этом году?

  4. Как известно, чтобы хорошо работать, необходим хороший отдых. А как ты отдыхал и сколько времени ушло на отдых?

Как видите, вопросы уже не работы касаются, а перекинулись на личную жизнь, но они актуальны для любого из нас.

И лично я, когда задавал себе эти вопросы - понял, что я ни черта не знаю о своем времени!

НИ-ЧЕ-ГО!

Про инструменты

Закончив книгу, я твердо для себя решил для начала разобраться с самим собой. Не должно быть противоречий в своих желаниях. Так же не должно быть навязанных "мудростей" от таких книг. Желание привести время в порядок должно родиться самостоятельно, не должно быть навязано кем-то и быть достаточным, чтобы разобраться в себе и начать с этим что-то делать.

Я решился вести учет личного и рабочего времени и веду его уже на протяжении полутора месяцев. На первых порах я не нашел нормального инструмента, который быпозволил мне фиксировать записи как я хочу. Из требований было: тратить на это минимальное количество времени, потом чтобы можно было проанализировать это помесячно. И на первых порах я пришел кGoogle Forms.

Завел вот такую форму:
Форма Google FormsФорма Google Forms

В ней ввел категории (которые потом и оставил):

  1. Работа (все рабочие моменты)

  2. Простой (все что относится к отбросам времени - например, дорога на работу)

  3. Поддержка семьи (покупка в магазине, что-то домой)

  4. Семья (время, которое я провожу с женой и детьми)

  5. Еда (без комментариев)

  6. Сон (без комментариев)

  7. Обучение (курсы, чтение литературы и повышение квалификации)

  8. Спорт (тренажерка, занятия с тренером)

  9. Хобби (есть свой YouTube канал, где я занимаюсь поделками и DIY)

  10. Здоровье (врачи, посещение больниц)

  11. Яркость жизни (путешествия, какие-то яркие события и действия)

  12. Друзья (общение и встречи с друзьями)

  13. Прочее (все что не отнеслось к категориям выше)

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

Выглядит это вот так:
Ответы при заполнении формыОтветы при заполнении формыА это лист с результатами ответов в виде таблицыА это лист с результатами ответов в виде таблицы

Дальше можно строить по этой таблицы разные графики.

Из плюсов отмечу то, что Google Forms отличный и быстрый сервис. Но через время стало понятно, что анализировать эту форму крайне трудно уже через пару дней ведения учета. А через два месяца это будет уже сплошная каша, которую надо будет как-то разгребать. На скриншотах, вроде бы все красиво, но когда таких записей становится пару тысяч, то уже не удобно.

Про мобильное приложение и трудности

Я решил поискать что-то готовое на эту тему и ничего не нашел, чтобы мне понравилось и подошло под мои запросы. Решил зайти со своей стороны Компания, в которой я работаю занимается разработкой ПО. У нас есть десктопная и мобильная версию программы, которая предназначена для ИТ-компаний (складской учет, комплекты/комплектующие,учет заявок пользователей, инвентаризации, учет ремонтов и прочее). Не буду спойлерить, не об этом речь. В общем приняли решение реализовать блок учета времени по Любищевув своем ПО.

Наше мобильное приложение работает как в связке с десктопом, так и без него. Причем, когда без него это вполне самостоятельное приложение, которое может использовать любой на Android и iOS, причемабсолютно бесплатно.

Трудно реализовать то, что не знаешь, как должно работать правильно и по канонам своего родоначальника, поэтому решил положиться в первую очередь на ощущение своего удобства. В самом начале сформулировал для себя задачи:

  • Создать документ "Ежедневныйотчет".Он должен иметь возможность ввода данных и хранить как за день, так и за период и "собирать" все работы в себе.

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

  • Надо что-то придумать с переходящими датами. Я ложусь спать в 22:00, проснусь в 7:00, приложение должно разбить на два временных участка одно и то же действия с 22:00 до 23:59:59 - сон, с 00:00 до 7:00 - сон.

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

  • Так же предполагается еще один разрез (Источник), который может быть заполнен, а может и нет. Это может быть, например, какой-то проект или задача. Если захотим потом по этому проекту посмотреть потраченное время.

  • Должны быть графики и обычные отчеты причем с разной степенью детальности и с разными аналитическими разрезами.

  • Необходимы другие документы такие какЕжемесячные/Ежегодные отчеты, которые бы накапливали данные по ежедневным отчетам. Что бы можно было попытаться выбрать все за последний месяц посидеть и подумать над затратами и отчитаться перед самим собой. Этого пока нет, только в планах.

Что получилось?

А получилось встроить в мобильное приложение к задачам этот блок с ежедневными отчетами, который отлично дополнил мобильное приложение и десктопную версию.

Для тех, кому не терпится посмотреть:

Ссылка в Google Play

Ссылка в AppStore

Как выглядит мобильное приложение
Главный экран мобильного приложенияГлавный экран мобильного приложенияДобавление работ с главного экрана. Дата/время с/по устанавливаются автоматически, как и длительностьДобавление работ с главного экрана. Дата/время с/по устанавливаются автоматически, как и длительностьЕжедневные отчеты. Все работы и дела идут последовательноЕжедневные отчеты. Все работы и дела идут последовательноА вот и отчеты по учету времени. Внизу разные варианты. Вверху сам отчет с настройкамиА вот и отчеты по учету времени. Внизу разные варианты. Вверху сам отчет с настройкамиГрафикиГрафики

Выводы

По личным ощущениям блок учета рабочего времени не идеальный, но в целом, я получил то, что хотел. Можно вводить текст с описанием работы с клавиатуры, а можно надиктовать, если писать слишком долго. В этом месяце я переболел Covid-19 и по графику видно (видно ли?) проседание рабочей производительности и в каком периоде это произошло. Я руководитель проектов и даже болея вынужден кому-то помогать, с кем-то говорить, а где-то написать письмо. Поэтому на графике практически нет не рабочих периодов.

Так же имея отчеты и диаграммы надо будет как-то анализировать это все. Я пока не пробовал т.к. хочу полноценно иметь какую-то статистику, которая позволит действительно что-то понять из общей картины.Ну и плюс моя болезнь, которая всегда не вовремя. А вот 06.11 меня настолько увлекла одназадача, что я потратил на нее неприлично много. 07.11 я почувствовал первые симптомы и дальше все на спад.

Из того, что сейчас можно сказать точно это интересно, даже если и не взлетит в отдаленной перспективе. Так же это весьма познавательно, когда открываешь случайный день и воспроизводишь его заново. Вдруг всплывают какие-то детали, дела, которые прошли, и ты про них "почти забыл". Не в плане что-то не сделал, а в плане каких-то мелочей, на которые не обратил внимание, а надо было бы. С удивлением понял, что рабочий день проходит хорошо, если действительно на рабочее время будет выделено в районе 5-6 часов. Обычно гораздо меньше получается. Даже элементарное попил кофе это минус 10 минут от рабочего, а в сумме таких кусочков набирается прям прилично. Об этом буду серьезно думать чуть позже. Осознавать это все весьма неожиданно.

Возможно, моя работа кому-то окажется полезной,буду очень рад. Так же буду рад фидбеку. Если у кого-то появятся стоящие идеи по дальнейшему развитию, то постараюсь этот функционал добавить.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru