Для тех везунчиков, которые пока не имели дела с 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 только по той причине, что какой-то эксперт по методике Agile рассказал, что Jira это хорошо и что на этой системе работают гибкие команды.
Между прочим, Atlassian (компания-разработчик Jira) постоянно ищет себе инженеров по различным направлениям, в числе прочих нужны Fullstack-разработчики и Java-разработчики. Если одна из ваших целей релоцироваться в компанию с мировым именем, то приходите учиться, прокачаем ваши скилы и поможем выгодно представить их в резюме.
Узнайте, как прокачаться в других специальностях или освоить их с нуля:
Другие профессии и курсыПРОФЕССИИ
КУРС
В одном, среднем по размеру российском Банке, есть интернет банк для физиков и юриков, сайты и мобильные приложения. А также есть подразделение, которое все это хозяйство сопровождает и развивает. Сюда и приходит молодой Руководитель, проработавший в этой организации уже более 3 лет, от лица которого и будет данное повествование.
Банк современный, процессы построены согласно ITIL, на первый взгляд все выглядит по учебнику. Как видно из названия статьи, мы затронем только один кусочек из интересующего нас процесса Внесения изменений.
Все в этом процессе было отлично за исключением одного момента, а именно согласования Аналитиком сроков разработки с Заказчиком владельцем продукта Интернет банк юридических лиц, каналы web+mobile, далее будем называть его просто Заказчиком. Заказчик всегда понимал и принимал работы, которые проходили у него на глазах или с его участием, а именно:
4. Определение длительности работ, для сотрудника категории
Senior:
2,2(СЕТ)/1,5(СЕТ/день)=1,6 дней
Длительность 1,6 дней
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 дня
Каждый из нас хотя бы раз в жизни задумывался о времени, его неумолимости и быстротечности.Вроде бы вчера ты окончил школу и поступил в университет, а уже сегодня тебе 36 лет, ты женат и у тебя двое детей, а по ощущениям тапропасть времени, которая прошла, слилась в один миг. Все очень стремительноНе так давно, в наше не простое время я был на онлайн-конференции слушателем и один из спикеров, известный предприниматель и основатель крупной ИТ-фирмы с множеством филиалов по всей России, говорил о своем личном и рабочем времени. Все как у всех:времени мало, то, что есть трудно распределить между важным и важным, плюс семья, одно накладывается на другое и в результате нет ни на что времени. Конференция была онлайн, докладчик был дома, выступая в череде таких же докладчиков, доклады которых слились в одно и слушались мною фоном.Но этот харизматичный человек как-то по-домашнему все рассказывал,даже показал нам свою собаку-пекинеса (чтобы вы понимали про атмосферу доклада). Столь необычная подача материала естественно приковала к себе мое внимание, и я начал внимательно его слушать. Речь была о книге Даниила Гранина "Эта странная жизнь" и методе Любищева, который практиковал автор доклада. Докладчик честно сказал, что эта вторая его попытка использовать этот метод в своей работе и личной жизни. На самом деле не понятно на сколько его хватит (намеренно не рассказываю о сути, т.к. позже постараюсь сделать это сам). А в конце доклада был совет прочесть эту книгу
В результате всего этого безобразия, я прочел книгу, впечатлился и появился блок учета времени по методу Любищева в мобильном приложении.
Мне стало интересно, и я ее прочел. Странное ощущение от ее чтения, скажу откровенно. Как будто сел ты на лавочку в парке, а на ней уже сидит пожилой человек (Гранин). Он начинает с тобой говорить и в какой-то момент ты уже сам не понимаешь, как так получилось, что ты очень внимательно его слушаешь и ловишь каждое слово. Это совсем не похоже на книжный рассказ, больше на настоящий монолог. А рассказывает он о своем знакомом - профессоре Любищеве Александре Александровиче, который занимался наукой и добился в своей научной работе огромных результатов. Причем не только в энтомологии (раздел зоологии, изучающий насекомых), основной своей специальности, но и куче других наук: философии, зоологии, генетике, истории науки, математике. Был достаточно уважаемым в абсолютно разных кругах ученным. Когда Гранин рассказывал про профессора, у меняскладывалось впечатление, что он очень сильно переживал. Причем в самом начале я не совсем понимал причину почему, столь умудренный годами старик так переживает свой рассказ, но чем больше он говорил, тем больше становилось понятно, что он проецировал жизнь своего товарища по науке на себя. Его серьезно что-то беспокоило Любищев был примером для Гранина и Гранин, глядя на то, как организовал свою научную и личную жизнь его знакомый, как мне показалось, корил себя. Корил за то, что в отличииот своего коллеги, он не знает сколько он читает книг, как с годами меняется его работоспособность, как много он проводит времени с семьей и т.д. Это был разбор и переосмысление подхода одного умного человека к работе и жизни как жил другой выдающийся человек. Любищев был олицетворением устремленности. Например, Любищев, будучи энтомологом классифицировал блошек и, в то время как он шел на работу, ловил этих блошек на улице. Его коллекция этих блошек была больше, чем в музеях того времени. При всем при этом он не тратил на это свое рабочее время! Фи Скажет читатель. "Так что в этом выдающегося?".Мужик собирал блох, по дороге на работу. Это не достижение
На самом деле это пример того, о чем мы бы и не подумали бы никогда. Человек не тратил на коллекционирование своего РАБОЧЕГО времени, но имел сумасшедшую коллекцию.
А как вам следующийпример? Любищеввыучил в дороге в "отбросах времени" английский язык. Скажи читатель: ты каждый рабочий день едешь в метро, ты выучил хоть что-нибудь? :) А ведь то время, которое ты едешь и ничем не занимаешь это же минус время из твоей жизни. А время, как известно, это самый ценный и не восстановимый ресурс. Вчера вернуть будет уже нельзя.
Конечно, ты не исключишь эти "отбросывремени" из своей жизни. Дорога на работу, очередив больнице, какие-то ожидания и все подобное, ты все равно потеряешь на это время.Так почему же не наполнить его чем-то полезным? Мне кажется это очень здравая идея. Это один из примеров грамотного тайм менеджмента. Но это самая малость. Давайте перейдем к серьезным вещам.
Начал вести Любищев свою систему с 26 лет и работал так до конца своих дней. Человек поставил цель всей своей жизни и шел к ней, не теряя эту цель. Суть же метода достаточно проста и сводилась к тому, что он фиксировал ВСЕ свое время как личное, так и любое другое со всей скрупулёзностьюи тщательностью, стараясь не тратить на учет много времени. Потом анализируясвои трудозатраты,мог точно сказать:
Насколько хорошо он отработал в этот период по сравнению с прошлым периодом?
Как многое из того, что он запланировал он выполнил и на сколько он продвинулся в этом?
Сколькоон написал статей, рукописей, прочел книг, посетил выставок и т.д.?
Более того, Любищев выработал в себе удивительную способность даже без часов точно знать время в течении дня и выработал"чувство времени". Понимал, где мы на временной шкале в течении дня. Это в свою очередь рождает осознанность потребления времени. А это вообще для сегодняшнего человека одно из важнейших качеств, и оно очень полезно.
Приведу очень хороший пример из нашей жизни.Навернякалюбой из вассталкивался с ситуацией, когда открываешь Ютубчик в обед в выходной день, начинаешь смотреть ролик, а потом еще, а потом еще Иглядь, через достаточно небольшой промежуток времени, а прошло уже часов 6 (!) При этом лично для вас время пролетело очень быстро. Любищев рассматривал время как что-то осязаемое и старался исключитьвот такие "быстрые" временные промежутки. Этого позволяет добиться как раз фиксирование времени, а фиксация порождает осознанность.
Ежедневный записи фиксировались с погрешностью в 10 минут, максимально коротко сокращались.Затем в конце месяца они группировались в месячные отчеты, месячные отчета анализировались и корректировались планы. Далее уже месячным отчеты трансформировались в годовые отчеты, а уже годовые отчеты сдавались и подводили итоги года. Причем сдача была перед самим собой и рассматривалась весьма категорически. Проводился анализ, где и как было упущено время, почему так произошло и как этого не допустить в будущем. Рассматривались причины, которые влияют на работоспособность. Например, его вторая жена и жизнь с ней были настолько хороши по-домашнему, что это сказывалось на его производительности. Весьма неожиданные выводы.
Через время появлялась статистика и можно было строить уже долго идущие планы вперед на основании потребления времени в прошлом.
Наверное, вы, как и я задались простыми вопросами: зачем мне это надо? Писать, что-то постоянно фиксировать и не забывать это фиксировать. Гранин уверен, что это просто необходимо. Возьмем для примера руководителя проектов (РП) или тимлида, хотя тут можно взять, наверное, любогои подобрать свои вопросы.
А сколько времени ты потратил за последний год на свое обучение?
Сколько рабочего времени ты тратишь не на профильные задачи?
И наоборот, сколько тратишь личного времени на рабочие вопросы?
Имеешь ли глобальную цель как руководитель проектов и на сколько далеко продвинулся в ее выполнении за последний год? А если этой цели нет, то, чего вообще хочешь от своей профессии?
Проблема в том, что ты этого не знаешь и вряд ли об этом даже задумывался Зачем вроде как это все тебе нужно? Я во всяком случае точно не задумывался.
А теперь возьмем твою личную жизнь.
Ты много работаешь, как часто в этом году ты проводил время с женой? С детьми?
Есть хобби? Если оно есть, много посвятил ему времени за последний год?
Как часто виделся со своими друзьями в этом году?
Как известно, чтобы хорошо работать, необходим хороший отдых. А как ты отдыхал и сколько времени ушло на отдых?
Как видите, вопросы уже не работы касаются, а перекинулись на личную жизнь, но они актуальны для любого из нас.
И лично я, когда задавал себе эти вопросы - понял, что я ни черта не знаю о своем времени!
НИ-ЧЕ-ГО!
Закончив книгу, я твердо для себя решил для начала разобраться с самим собой. Не должно быть противоречий в своих желаниях. Так же не должно быть навязанных "мудростей" от таких книг. Желание привести время в порядок должно родиться самостоятельно, не должно быть навязано кем-то и быть достаточным, чтобы разобраться в себе и начать с этим что-то делать.
Я решился вести учет личного и рабочего времени и веду его уже на протяжении полутора месяцев. На первых порах я не нашел нормального инструмента, который быпозволил мне фиксировать записи как я хочу. Из требований было: тратить на это минимальное количество времени, потом чтобы можно было проанализировать это помесячно. И на первых порах я пришел кGoogle Forms.
Завел вот такую форму:В ней ввел категории (которые потом и оставил):
Работа (все рабочие моменты)
Простой (все что относится к отбросам времени - например, дорога на работу)
Поддержка семьи (покупка в магазине, что-то домой)
Семья (время, которое я провожу с женой и детьми)
Еда (без комментариев)
Сон (без комментариев)
Обучение (курсы, чтение литературы и повышение квалификации)
Спорт (тренажерка, занятия с тренером)
Хобби (есть свой YouTube канал, где я занимаюсь поделками и DIY)
Здоровье (врачи, посещение больниц)
Яркость жизни (путешествия, какие-то яркие события и действия)
Друзья (общение и встречи с друзьями)
Прочее (все что не отнеслось к категориям выше)
Пока так, возможно в будущем этот список будет изменен и подкорректирован. Google-формы позволяют собирать ответы на вопросы формы в файлы таблиц, где фиксируется время каждого ответа, есть возможность повторного заполнения форм. Если вести фиксацию времени непрерывно, то заполнение формы и ее отправка будет являться временным отрезком от последнего фиксирования. Это позволит вести полноценный учет времени.
Выглядит это вот так:Дальше можно строить по этой таблицы разные графики.
Из плюсов отмечу то, что Google Forms отличный и быстрый сервис. Но через время стало понятно, что анализировать эту форму крайне трудно уже через пару дней ведения учета. А через два месяца это будет уже сплошная каша, которую надо будет как-то разгребать. На скриншотах, вроде бы все красиво, но когда таких записей становится пару тысяч, то уже не удобно.
Я решил поискать что-то готовое на эту тему и ничего не нашел, чтобы мне понравилось и подошло под мои запросы. Решил зайти со своей стороны Компания, в которой я работаю занимается разработкой ПО. У нас есть десктопная и мобильная версию программы, которая предназначена для ИТ-компаний (складской учет, комплекты/комплектующие,учет заявок пользователей, инвентаризации, учет ремонтов и прочее). Не буду спойлерить, не об этом речь. В общем приняли решение реализовать блок учета времени по Любищевув своем ПО.
Наше мобильное приложение работает как в связке с десктопом, так и без него. Причем, когда без него это вполне самостоятельное приложение, которое может использовать любой на Android и iOS, причемабсолютно бесплатно.
Трудно реализовать то, что не знаешь, как должно работать правильно и по канонам своего родоначальника, поэтому решил положиться в первую очередь на ощущение своего удобства. В самом начале сформулировал для себя задачи:
Создать документ "Ежедневныйотчет".Он должен иметь возможность ввода данных и хранить как за день, так и за период и "собирать" все работы в себе.
Быстрый и удобный вводданных. Все должно быть быстро. Не надо вводить постоянно время, его можно показать и установить текущим, причем прошлое время тоже нам известно оно ведь нами добавляется ранее. Время начала и окончания можно вычислить (при условии непрерывной фиксации).
Надо что-то придумать с переходящими датами. Я ложусь спать в 22:00, проснусь в 7:00, приложение должно разбить на два временных участка одно и то же действия с 22:00 до 23:59:59 - сон, с 00:00 до 7:00 - сон.
Категории пока буду вводить вручную, но в целом можно в будущем попробовать на основании уже введенных данных через промежуток времени использовать машинное обучение и устанавливать в полуавтоматическом режиме. Когда категория устанавливается автоматически после ввода текста, но мы можем ее поправить если вдруг, она определила что-то не верно.
Так же предполагается еще один разрез (Источник), который может быть заполнен, а может и нет. Это может быть, например, какой-то проект или задача. Если захотим потом по этому проекту посмотреть потраченное время.
Должны быть графики и обычные отчеты причем с разной степенью детальности и с разными аналитическими разрезами.
Необходимы другие документы такие какЕжемесячные/Ежегодные отчеты, которые бы накапливали данные по ежедневным отчетам. Что бы можно было попытаться выбрать все за последний месяц посидеть и подумать над затратами и отчитаться перед самим собой. Этого пока нет, только в планах.
А получилось встроить в мобильное приложение к задачам этот блок с ежедневными отчетами, который отлично дополнил мобильное приложение и десктопную версию.
Для тех, кому не терпится посмотреть:
Как выглядит мобильное приложениеПо личным ощущениям блок учета рабочего времени не идеальный, но в целом, я получил то, что хотел. Можно вводить текст с описанием работы с клавиатуры, а можно надиктовать, если писать слишком долго. В этом месяце я переболел Covid-19 и по графику видно (видно ли?) проседание рабочей производительности и в каком периоде это произошло. Я руководитель проектов и даже болея вынужден кому-то помогать, с кем-то говорить, а где-то написать письмо. Поэтому на графике практически нет не рабочих периодов.
Так же имея отчеты и диаграммы надо будет как-то анализировать это все. Я пока не пробовал т.к. хочу полноценно иметь какую-то статистику, которая позволит действительно что-то понять из общей картины.Ну и плюс моя болезнь, которая всегда не вовремя. А вот 06.11 меня настолько увлекла одназадача, что я потратил на нее неприлично много. 07.11 я почувствовал первые симптомы и дальше все на спад.
Из того, что сейчас можно сказать точно это интересно, даже если и не взлетит в отдаленной перспективе. Так же это весьма познавательно, когда открываешь случайный день и воспроизводишь его заново. Вдруг всплывают какие-то детали, дела, которые прошли, и ты про них "почти забыл". Не в плане что-то не сделал, а в плане каких-то мелочей, на которые не обратил внимание, а надо было бы. С удивлением понял, что рабочий день проходит хорошо, если действительно на рабочее время будет выделено в районе 5-6 часов. Обычно гораздо меньше получается. Даже элементарное попил кофе это минус 10 минут от рабочего, а в сумме таких кусочков набирается прям прилично. Об этом буду серьезно думать чуть позже. Осознавать это все весьма неожиданно.
Возможно, моя работа кому-то окажется полезной,буду очень рад. Так же буду рад фидбеку. Если у кого-то появятся стоящие идеи по дальнейшему развитию, то постараюсь этот функционал добавить.