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

Планирование

Что может пойти не так с Data Science? Сбор данных

17.07.2020 14:11:33 | Автор: admin

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

Поэтому мы начинаем серию заметок Что может пойти не так с Data Science, основанных на реальных событиях случившихся со мной, моими товарищами и коллегами. Будем разбирать на реальных примерах типичные задачи по Data Science: как это на самом деле происходит. Начнем сегодня с задачи сбора данных.

И первое обо что спотыкаются люди, начав работать с реальными данными это собственно сбор этих самых релевантных нам данных. Ключевой посыл этой статьи:

Мы систематически недооцениваем время, ресурсы и усилия на сбор, очистку и подготовку данных.

А главное, обсудим, что делать, чтобы этого не допустить.

По разным оценкам, очистка, трансформация, data processing, feature engineering и тд занимают 80-90% времени, а анализ 10-20%, в то время как практически весь учебный материал фокусируется исключительно на анализе.

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

И для примера опять же, мы рассмотрим подобные вариации задачи сбора данных и сравнения сообществ для:

  1. Двух сабреддитов Reddit
  2. Двух разделов Хабра
  3. Двух групп Одноклассников

Условный подход в теории


Открыть сайт и почитать примеры, если понятно, заложить несколько часов на чтение, несколько часов на код по примерам и отладку. Добавить несколько часов на сбор. Накинуть несколько часов про запас (умножить на два и прибавить N часов).

Ключевой момент: временная оценка основана на предположениях и догадках о том, сколько это займет времени.

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

  • Какой размер данных и сколько его нужно физически собирать (*см ниже*).
  • Какое время сбора одной записи и сколько нужно ждать, прежде чем можно собрать вторую.
  • Заложить написание кода сохраняющего состояние и начинающего рестарт, когда (а не если) все упадет.
  • Разобраться, нужна ли нам авторизация и заложить время получения доступа по API.
  • Заложить количество ошибок, как функцию сложности данных оценить по конкретной задаче: структура, сколько преобразований, что и как экстрактим.
  • Заложить ошибки сети и проблемы с нестандартным поведением проекта.
  • Оценить, если нужные функции в документации и если нет, то как и сколько нужно для a workaround.

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

И сейчас мы продемонстрируем конкретные примеры, где такие параметры и будут меняться.

Ключевой момент: оценка основана на анализе ключевых факторов, влияющих на объем и сложность работы.

Оценка, основанная на догадках это хороший подход, когда функциональные элементы достаточно небольшие и не так много факторов, которые могут существенно повлиять на структуру задачи. Но в случае ряда задач Data Science таких факторов становится крайне много и подобный подход становится неадекватным.

Сравнение сообществ Reddit


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

  • Имеется аккуратный, понятный и документированный API.
  • Крайне просто и главное автоматически получается токен.
  • Есть python wrapper с кучей примеров.
  • Сообщество которое занимается анализом и сбором данных на реддите (вплоть до youtube роликов объясняющих, как использовать python wrapper) вот например.
  • Нужные нам методы скорее всего существуют в API. Более того, код выглядит компактно и чисто, ниже пример функции собирающей комментарии к посту.

def get_comments(submission_id):    reddit = Reddit(check_for_updates=False, user_agent=AGENT)    submission = reddit.submission(id=submission_id)    more_comments = submission.comments.replace_more()    if more_comments:        skipped_comments = sum(x.count for x in more_comments)        logger.debug('Skipped %d MoreComments (%d comments)',                     len(more_comments), skipped_comments)    return submission.comments.list()
Взято из этой подборки удобных утилит для обертки.

Несмотря на то что перед нами самый лучший случай здесь все же стоит учесть ряд важных факторов из реальной жизни:

  • Лимиты API мы вынуждены брать данные батчами (спать между запросами и тд).
  • Время сбора для полного анализа и сравнения придется заложить существенное время просто для паука пройтись по сабреддиту.
  • Бот должен крутиться на сервере вы не можете просто запустить его на ноуте, сложить в рюкзак и поехать по делам. Поэтому я запустил все на VPS. По промокоду habrahabr10 можно сэкономить еще 10% стоимости.
  • Физическая недоступность некоторых данных (они видны админам или слишком сложно собираются) это надо учесть, не все данные в принципе можно собрать за адекватное время.
  • Ошибки работы сети: работа с сетью это боль.
  • Это живые настоящие данные они чистыми не бывают.

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

Сравнение разделов Хабра


Переходим к более интересному и нетривиальному случаю сравнению потоков и/или разделов Хабра.

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

  • Сначала вы думаете, что есть API, но его нет. Да-да, у Хабра есть API, но только он недоступен для пользователей (а может и совсем не работает).
  • Потом просто начинаете парсить html import requests, что может пойти не так?
  • А как вообще парсить? Самый простой и часто используемый подход итерировать по ID, отметим, что не самый эффективный и придется обрабатывать разные случаи вот для примера плотность реальных ID среди всех существующих.


    Взято из этой статьи.
  • Сырые данные, завернутые в HTML поверх сети это боль. Например, вы хотите собрать и сохранить рейтинг статьи: выдрали score из html и решили сохранить его как число для дальнейшей обработки:

    1) int(score) кидает ошибку: так как на Хабре минус, как, например в строке "5" это короткое тире, а не знак минуса (неожиданно, да?), поэтому в какой-то момент пришлось поднимать парсер к жизни вот с таким ужасным фиксом.

    try:      score_txt = post.find(class_="score").text.replace(u"","-").replace(u"+","+")      score = int(score_txt)      if check_date(date):        post_score += score
    

    Даты, плюсов и минусов может вообще не быть (как мы видим выше по функции check_date и такое было).

    2) Неэкранированные спецсимволы они придут, нужно быть готовым.

    3) Структура меняется в зависимости от типа поста.

    4) Старые посты могут иметь **странную структуру**.
  • По сути обработку ошибок и что может или не может произойти придется обрабатывать и нельзя предугадать наверняка, что пойдет не так и как еще может быть структура и что где отвалится придется просто пробовать и учитывать ошибки, которые бросает парсер.
  • Потом вы понимаете, что нужно парсить в несколько потоков иначе парс в один потом займет 30+ часов (это чисто время выполнения уже рабочего однопоточного парсера, который спит и не попадает ни под какие баны). В этой статье, это привело в какой-то момент к подобной схеме:



Итого чеклист по сложности:

  • Работа с сетью и парсом html с итерацией и перебором по ID.
  • Документы неоднородной структуры.
  • Много мест, где код может легко упасть.
  • Необходимо писать || код.
  • Отсутствует нужная документация, примеры кода и/или сообщество.

Условная оценка времени для данной задачи будет в 3-5 раз выше, чем для сбора данных с Реддита.

Сравнение групп Одноклассников


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

Начнет с нашего чеклиста сложности и отметим, что многие из них окажутся куда сложнее, чем выглядят вначале:

  • API есть, но в нем почти полностью отсутствуют нужные функции.
  • К определенным функциям нужно просить доступ по почте, то есть выдача доступа не мгновенная.
  • Он ужасно документирован (начнем с того, что всюду мешаются русские и английские термины, причем абсолютно непоследовательно иногда вам нужно просто угадать, что от вас где-то хотят) и, более того, не подходит по дизайну для получения данных, например, нужной нам функции.
  • Требует сессии в документации, а на деле ее не использует и нет никакого способа разобраться во всех тонкостях режимов API, кроме как тыкаться и надеяться, что что-то будет работать.
  • Отсутствуют примеры и сообщество, единственная точка опоры в сборе информации небольшой wrapper на питоне (без большого количества примеров использования).
  • Наиболее рабочим вариантов выглядит Selenium, так как многие нужные данные под замком.
    1) То есть идет авторизация через фиктивного пользователя (и регистрация ручками).

    2) Однако c Selenium никаких гарантий по корректной и повторяемой работе (по крайней в случае с ok.ru точно).

    3) Сайт Ок.ру содержит ошибки JavaScript и иногда странно и непоследовательно себя ведет.

    4) Нужно заниматься пагинацией, подгрузкой элементов и тд

    5) Ошибки API, которые отдает wrapper придется костыльно обрабатывать, например, вот так (кусочек экспериментального кода):

    def get_comments(args, context, discussions):    pause = 1    if args.extract_comments:        all_comments = set()#makes sense to keep track of already processed discussions        for discussion in tqdm(discussions):             try:                comments = get_comments_from_discussion_via_api(context, discussion)            except odnoklassniki.api.OdnoklassnikiError as e:                if "NOT_FOUND" in str(e):                    comments = set()                else:                    print(e)                    bp()                    pass            all_comments |= comments            time.sleep(pause)        return all_comments
    

    Моя любимая ошибка была:

    OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: ))

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

Условная оценка времени для данной задачи будет в 3-5 раз выше, чем для сбора данных с Хабра. Несмотря на то что в случае с Хабром мы используем лобовой подход с парсом HTML, а в случае с ОК мы можем в критичных местах работать с API.

Выводы


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

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

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

Если пробежаться краем глаза по характеристикам задачи без дополнительных экспериментов, то Reddit и ОК выглядят похоже: есть API, python wrapper, но по сути, разница огромна. Если судить по этим параметрам, то парс Хабра выглядит сложнее, чем ОК а на практике это совсем наоборот и именно это можно выяснить, проведя простые эксперименты по анализу параметров задачи.

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

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

Подробнее..

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

15.08.2020 00:07:43 | Автор: admin

Что такое дедукция?


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

image

Пример дедуктивного рассуждения в логике


Дедукция известна со времен Аристотеля. Именно Аристотель рассматривал умозаключения с посылками и выводом.

Пример дедуктивного умозаключения:

Все люди смертны.
Сократ человек.
Следовательно, Сократ смертен.

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

Применение дедуктивных рассуждений в повседневной жизни


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

image

Представим, как бы рассуждал сыщик. Допустим мы находимся вне города и видим человека, который несёт рыбу.

Исходное знание человек несет рыбу. Далее наше рассуждение выглядит так. Мы можем предположить, что, первое, человек купил эту рыбу в магазине. Но магазина рядом нет, так что скорее всего он взял рыбу у кого-то или поймал ее сам. Если человек поймал рыбу сам, то тогда у него должно быть удочки с собой. Но удочки у него нет. Тогда, возможно, удочка осталась на берегу или у него вовсе не было удочки. Если у этого человека нет удочки вовсе, то он взял рыбу у кого-то. Сыщику достаточно будет посмотреть, нет ли на берегу удочки. Если она есть то этот человек сам выловил рыбу. Если ее нет, то человек взял у кого-то эту рыбу.
Это пример дедуктивного рассуждения: есть исходное общее знание, и далее мы рассматриваем частности и детали.

Пример дедуктивного рассуждения при принятии решения


image

У Андрея сейчас уровень английского языка чуть ниже среднего. Он хочет достичь среднего уровня английского языка (B1) через 3 месяца. Рассмотрим рассуждения Андрея.
Если я буду заниматься самостоятельно, то мне нужно будет самому искать учебные материалы, упражнения и выполнять задания без проверки преподавателя. Тогда я должен буду запланировать 3 часа в день на занятия английским, чтобы через 3 месяца достичь уровня B1.

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

Заниматься самостоятельно или заниматься с преподавателем


Заниматься самостоятельно

Запланировать 3 часа на занятия английским языком в день.
Я достигну уровня B1 через 3 месяца.

Заниматься с преподавателем

Запланировать 2 часа в день на занятия английским языком.
Я достигну уровня B1 через 3 месяца.

Я достигну уровня B1 через 3 месяца.

Как дедуктивный метод помогает в жизни?

  1. Цель определяется заранее.
  2. Рассматриваем варианты того, как вы ее можете достигнуть.
  3. На принятие решения не оказывают влияние эмоции.
  4. На принятие решения не оказывают влияния советы третьих лиц.
  5. Вы сами выбираете направление, которое вам позволит прийти к цели.
  6. Вы можете выбрать наиболее экономичное (в денежном или время затратном плане) решение.

image

Применение дедуктивного метода в преподавании и аналитической работе


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

image

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

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

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

Применение дедуктивного метода в когнитивно-поведенческой психологии


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

image

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

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

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

Недостатки дедуктивного подхода


Рассмотрим на примере использования этого метода в преподавании иностранного языка.

  1. Начинать урок с презентации грамматики может быть трудоемким и сложным для некоторых студентов, особенно начального уровня. Они могут не знать специфической терминологии для объяснения грамматики. Кроме того, они могут не понимать некоторые более простые грамматические конструкции.
  2. Объяснение грамматики переводит центр внимания на преподавателя, тем самым уменьшая количество времени, которое можно использовать на взаимодействие студентов друг с другом. Тем самым, не уделяется основное время урока на отработку навыков общения и использование языка в речи.
  3. Объяснение не так хорошо воспринимается, как другие формы презентации материала, как например наглядная демонстрация.
  4. Такой подход может внушить студенту мысль, что знание языка это просто знание некоторого набора правил.

Дедуктивный метод имеет множество преимуществ, рассмотрим некоторые из них.

Преимущества дедуктивного метода


  1. Он сразу достигает поставленной цели, и поэтому может быть экономным в плане финансовых затрат. Многие правила, в особенности правила грамматической формы, может быть просто и быстро объяснено, затем выявляться из примеров. Это дает больше времени на практику и применение правил.
  2. Дедуктивный метод признает знания и зрелость студентов, а также роль когнитивных процессов в освоении языка.
  3. Он оправдывает ожидания многих студентов от процесса обучения, в особенности тех студентов, у которых аналитический стиль изучения нового материала.
  4. Он позволяет преподавателям иметь дело с различными особенностями языка в процессе урока вместо того, чтобы предполагать заранее те вопросы, которые могут возникнуть и готовиться к ним до урока.

Литература:

Thornbury S. How to Teach Grammar. Pearson Education Limited, 1999
Johan van Benthem, Hans van Ditmarsch, Jan van Eijck, Jan Jaspars. Logic in Action, 2016
Фотографии взяты из открытого источника www.pexels.com
Подробнее..

Список задач vs Календарь сравнение инструментов управления задачами

25.12.2020 18:10:30 | Автор: admin

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



Сравнение внешнего вида Todoist и Google Calendar


Список задач


Чаще всего люди, начинающие практиковать тайм-менеджмент используют для этого списки задач. Приложения для списков задач представляют из себя один или несколько таких списков с различными функциями управления. Каждая задача может быть отмечена завершенной с помощью галочки слева. Часто бывает возможность выставить еще множество других атрибутов, таких как приоритет, планируемую дату, время начала и т.д. Примеры приложений: Todoist, Microsoft Todo, Google Tasks, Things. Какие же у списков задач преимущества перед календарем?


1. Удобство использования


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



Добавление задачи в список входящих в Todoist


2. Возможность завершить задачу


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



Завершение задач в Microsoft ToDo


3. Визуальное представление


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


4. Просроченные задачи в приоритете


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



Просроченные задачи в Todoist


5. Планы


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



План в виде списка задач в Todoist


6. Фокус на целях


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


Календарь


Чаще всего, календарь используют как вспомогательный инструмент для хранения мероприятий с фиксированной датой и временем. Я рассмотрю подход, в котором все задачи заносятся в календарь и имеют четкую дату и время начала. Приложения для календарей также предлагают возможность управления своими задачами. Примеры таких календарей Google Calendar, Apple Calendar, Microsoft Outlook. Есть 2 больших функциональных отличия: это возможность установить продолжительность задачи и совершенно иной способ отображения задач. Эти отличия основа для множества психологически ориентированных отличий.


1. Расписание


Планирование в календаре дает вам возможность представить предстоящие дни или недели в виде расписания. Кто-то может возразить, мол, жить по расписанию, как робот, это скучно. Но, во-первых, ни один инструмент сам по себе не может вас заставить следовать по заранее заданному графику. Ни список задач, ни календарь, ни что-то еще. Во-вторых, этого от вас и не требуется. Бывает так, что я практически ничего из запланированного не сделал за весь день. Ничего страшного, это бывает, будут дни получше. В таком случае, я просто переношу все свои задачи на другие дни. Т.е. основная идея это в том, чтобы поддерживать ваш календарь или список задач в актуальном состоянии. Кроме того, при наличии расписания, вам проще запланировать встречу, потому что вы всегда знаете, когда у вас есть свободное время. Вы можете планировать свой день или неделю так, чтобы осталось время на отдых. А если у вас много задач в один день, то вы можете оставлять немного свободного времени между ними, чтобы было проще между ними переключаться. Как и со списком задач, у вас есть четкое понимание, что делать сегодня, но кроме этого вы еще и примерно представляете сколько времени это займет.



Расписание задач в Google Calendar


2. Временные ограничения


Это самый большой плюс календаря, по-моему мнению. У вас есть ограничение на объем задач в день. Как минимум это человеческие сутки 24 часа. Если вы спите, то еще меньше. Если вы планируете рабочие задачи, то ограничением для вас будут рабочие часы. Итак, допустим, вы расписали день так, что он забит под завязку. И случается одно из двух: вы не успеваете что-то сделать или приходит новая более срочная задача. В силу временных рамок приходится какие-то задачи перенести на следующие дни. Это может показаться неудобным, но такое планирование предохраняет нас от выгорания. Если даже у вас есть какая-то суперсрочная задача, то попробуйте сначала взвесить свои шансы на ее выполнение сегодня. В моей практике я чаще уходил спать в 3 ночи с невыполненной задачей, чем доделывал ее. Если вы чувствуете, что не сможете сделать задачу сегодня, то "отщепите" кусочек задачи, продублировав ее в календаре и перенесите этот кусочек, допустим, на завтра. Кроме того, разделение в календаре по дням способствует тому, чтобы вы чаще декомпозировали свои задачи.



Перенос задачи из-за более срочной в Google Calendar


3. Временные блоки для задач


Используя календарь вы можете организовать свою деятельность с помощью временных блоков или time-blocking. Наше сознание по своей природе однозадачно. Поэтому я стараюсь делать так, чтобы все мои задачи не накладывались одна на другую. В результате, у меня есть одна конкретная задача в любой момент времени и мне нет необходимости отвлекаться на другое. Это помогает сконцентрироваться. Кроме того, иметь несколько задач в календаре одновременно доставляет визуальное неудобство они налезают друг на друга и прочитать их затруднительно. Однако, есть исключения, когда мы можем совмещать две деятельности вместе: например, прогулка и звонок другу, или совещание, на котором требуется ваше пассивное присутствие и какая-то рабочая задача. Если у вас уже есть какие-то мероприятия с фиксированной датой и временем, то вы можете строить свои планы вокруг них. Не начинайте большую задачу требующую концентрации в день, когда у вас много совещаний. Постоянные переключения будут вас отвлекать. Лучше попробуйте в этот день сделать короткие задачи, а для большой освободите место на другие дни.



Многозадачность в Google Calendar


4. Фактически проведенное время


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



Завершенные задачи окрашенные в зеленый цвет в Google Calendar


5. Откладывание на потом неудобно


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



Прогрессирующая прокрастинация в Google Calendar


6. Оценка сроков


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


Чем пользуюсь я?


Я много раз пробовал списки задач. Может быть, я не относился к этому достаточно серьезно. Тем не менее, как-то раз я начал пользоваться планированием своих задач в календаре, сначала на работе, потом и в личной жизни. Не все сразу, но постепенно я добавлял туда все больше фактических временных затрат, а потом и задач. Я выбрал Google Calendar и пользовался им на протяжении года как приложением для ведения задач. И вот что я хочу сказать: и календарь и список задач наполнены одинаковыми сущностями, то есть структура по сути одна, за исключением того, что в календаре задачи имеют продолжительность. Основная разница в отображении этих задач и пользе при планировании. Если вы четко знаете цель и планируете в контексте целей, то список задач удобнее. Если вы хотите планировать в контексте времени и соблюдать баланс между отдыхом и работой, то лучше используйте календарь. Календарь научил меня лучше чувствовать время, наблюдать за своей продуктивностью и планировать свой отдых. Но все же, мне иногда не хватало обзора своих целей и планов, удобного отображения и средства ввода задач. Дошло до того, что я уже начал разрабатывать свое собственное приложение, которое бы совмещало в себе и список задач и календарь, пока наткнулся на TickTick. Это приложение для ведения задач с заданой продолжительностью, которое содержит в себе 2 отображения: список задач и календарь. Да, в нем есть парочку серьезных неудобств, заметных после Google Calendar, но их можно простить из-за самой идеи и реализации. Для себя лично я нашел TickTick идеально подходящим для планирования и организации жизни.

Подробнее..

Перевод Что такое SDLC? Этапы, методология и процессы жизненного цикла программного обеспечения

02.10.2020 12:06:25 | Автор: admin
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, жизненный цикл проекта охватывает всю деятельность проекта. Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?

Ответить можно так: направить ваш рабочий процесс в верном направлении поможет подходящий фреймворк. В наши дни довольно сильным и популярным фреймворком является SDLC жизненный цикл программного обеспечения.

Принципы работы SDLC и почему им пользуются


На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.



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

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

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

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

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

Этапы SDLC и лучшие практики и методологии


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

  • Анализ требований отвечает на вопрос Какие проблемы требуют решений?
  • Планирование отвечает на вопрос Что мы хотим сделать?
  • Проектирование и дизайн отвечает на вопрос Как мы добьемся наших целей?
  • Разработка ПО регулирует процесс создания продукта.
  • Тестирование регулирует обеспечение качественной работы продукта.
  • Развертывание регулирует использование финального продукта.

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

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

Этап #1: Анализ требований


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

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

Этап #2: Планирование


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

Хороший пример:

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

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

Этап #3: Проектирование и дизайн


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

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

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

Этап #4: Разработка ПО


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

Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе и приступайте к делу.

Этап #5: Тестирование


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

Этап #6: Развертывание


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

Объединяя все вместе: подход SDLC


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

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

Разработка ПО может быть трудным, и в то же время полезным занятием.

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

Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?

Сформулировав эти вопросы вокруг SDLC, он смог лучше отточить свой финальный продукт и предоставить нужные инструменты правильным пользователям. Он сузил свой кругозор до более строгого определения его проблемной области и смог выделить ресурсы на планирование еще до того как он начал делать что-либо еще.

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

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

Следовательно, цикл продолжается.

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

Фраза Создавать круто должна стать вашей путеводной звездой, а SDLC инструментом и помощником.
Подробнее..

Встречи планирования разработки в пандемию, или Как устроить электро PIP

15.04.2021 14:13:15 | Автор: admin
Сегодня мне хотелось бы с помощью моих коллег Agile-коучей Ани Родионовой, Макса Зотова и владельца продукта в Трайбе Розничное взыскание и урегулирование Свята Божухина рассказать о практике применения интересного инструмента. Итак, речь пойдёт о Program Increment Planning Meeting aka PI Planning.

Это метод планирования из SAFe (Scaled Agile Framework) гибкого фреймворка для крупных компаний. Ну, знаете, это когда люди стоят у стены, оклеенной стикерами, лепят всякие ниточки от одного стикера к другому, но при этом в городе не орудует маньяк.

Ниже пример места встречи одной из команд для PI в Сбере (обратите внимание на ту самую стену на заднем плане):

image

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

С чего началось


В марте 2020 года бОльшая часть команд перешла на дистанционный формат работы. Со встречами по планированию нужно было что-то делать. С технической точки зрения у нас были Zoom и Confluence, но организационно нужно было немного докрутить.

Вот так выглядит SAFe, и скромную часть в нём занимает PI:

image

Вот что должны сделать разные участники, чтобы планирование прошло успешно:

image

На планировании руководителям нужно было рассказать о цели продукта за квартал так, чтобы у мини-команд, которые оказались на самоизоляции, было целостное понимание картины.

Scrum-мастерам поручили подготовить все шаблоны флипов (флипчартов). В онлайне они трансформировались в таблички на Confluence в специальном пространстве для совместной работы.

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

Группа фасилитаторов следила за тем, чтобы все шаблоны в Confluence были подготовлены и всё логистически готово.

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

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

Сама история почти не поменялась: если раньше были физические флипчарты, то теперь они стали виртуальными.

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

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

image

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

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

image

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

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

Процесс


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

Дальше идёт работа команд:

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

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

В электронном виде стало удобнее: появилась чёткая структура, добавилась лучшая сохранность артефактов. Каждая задача ставится в Confluence.

В среднем из запланированного делается по факту 7080 %. Это очень качественный показатель.

Инвестиция в будущее


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

Вот так, если вкратце про PI Planning. Если хотите больше подробностей, то можно посмотреть выступление коллег тут.
Подробнее..

Почему Скотт пришёл к Южному Полюсу вторым, а Амундсен предпоследним

14.06.2021 14:06:00 | Автор: admin


Если ты ненадёжен то не стоит руководить полярной экспедицией.
Хотя если ты самонадеян до крайности как ты сам догадаешься о своей некомпетентности?

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

Суть дела: в январе 1911 в Антарктиде высадились две экспедиции: британская Роберта Скотта и норвежская Руаля Амундсена. Оба хотели достигнуть Южного полюса последнего места на Земле, где ещё не побывал человек. Группы перезимовали у побережья и стартанули к полюсу почти одновременно. Кто успевал первым, тому и должна была достаться вся слава.



Каноничная карта маршрутов двух экспедиций

Шли параллельными маршрутами. У норвежцев путь от бухты до полюса был чуть короче, но они шли по неизведанному пути.
Англичане шли дорогой, которую уже разведал британец Эрнест Шеклтон в 1907 году. Тогда он не дошёл до полюса 180 км.

Однако Амундсен и его группа пришли на полюс раньше, потусили там трое суток и благополучно вернулись на базу. Скотт и четверо его компаньонов оказались у полюса на 34 дня позже норвежцев. И все погибли на обратном пути. У троих ещё были шансы выжить, но они замёрзли в палатке без еды и горючего, пока пережидали буран в течении 9 дней. До спасительного склада с продовольствием и керосином им оставалось пройти всего 18 километров.

Экспедиция Скотта была плохо спланирована и организована. Ответственность за это должен нести командир. Но всё искупила героическая гибель. Через 8 месяцев спасательная экспедиция с побережья нашла палатку с трупами. Нашли письма и дневник Скотта, фотоматериалы и даже геологические образцы, которые экспедиция не бросила до последнего.

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


Руаль Амундсен, Хельмер Хансен, Сверре Хассель и Оскар Вистинг на Южном полюсе в декабре 1911 (Из архива Национальной библиотеки Норвегии)

Вот вам типичное сообщение британской газеты:
Скотт пришёл к полюсу вторым. Амундсен предпоследним!

Если бы по горячим следам было проведено расследование и сделаны выводы может это помогло бы британцам лучше планировать крупные операции, типа высадки в Галлиполи? Да ну, бред какой-то.

Давайте пройдёмся по некоторым аспектам экспедиции и оценим разный подход Скотта и Амундсена к планированию и управлению людьми.

1. Люди.
Кого вы возьмёте, чтобы идти 1300 км через ледяную пустыню и горы?
(а потом ещё столько же обратно).
Ну наверно подготовленных лыжников или опытных полярников?

В береговой партии Скотта было 65 человек: флотские офицеры, учёные, простые матросы. Группа для финального рывка к полюсу должна была состоять из четверых человек, включая самого Скотта:
Эдвард Уилсон зоолог, врач и художник
Лоуренс Отс кавалерист, внёс в фонд экспедиции 1000 фунтов за право пойти к полюсу
Эдгар Эванс моряк.

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

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

2. Транспорт
Как тащить припасы?
Скотт был опытный полярник, в 1901-1903 он уже руководил экспедицией в Антарктике. Всему учился на опыте, но не факт, что сделал верные выводы.
Скептически относился к: собакам и лыжам.
Допускал использование лошадей (маньчжурской породы).
Но основную ставку делал на пешую тягу.
План был такой: от побережья заброс снаряжения делают мотосани (3 штуки). Дальше караван из лошадей и собак. А на финальном рывке (700 км до полюса) груз тянут люди.
Мотосани не помогли. Первые утонули при разгрузке с корабля. Двое других послужили недолго и скоро вышли из строя.

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

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

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

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

Да, и лыжи. Пока собаки бежали в упряжках, люди бежали рядом на лыжах.

3. Еда
Рацион у обоих экспедиций был примерно одинаков, суточная доза составляла 4500 калорий:
пеммикан (сушёное мясо с жиром), сухое молоко, шоколад, галеты.
Амундсен использовал чуть больше свежего мяса тюленей (добытых ранее на побережье) и собачатину.
Плюс Амундсен испытывал новинку: пеммикан с добавкой сушёных овощей и овсяных хлопьев (спонсором выступила норвежская армия). Норвежцы меньше страдали от недостатка витамина В12.
А за счёт того, что быстро сгоняли на полюс и обратно, не успели заболеть цингой.
Амундсен рассчитал еду с запасом, на обратном пути они даже сбрасывали лишнее продовольствие.


Ежедневный рацион участника экспедиции Скотта: какао, пеммикан, сахар, печенье, масло.

Однажды норвежцы встретили у своей палатки императорского пингвина. Убили его и съели (true story).

У Скотта в принципе было всё рассчитано с количеством еды (если не считать лишнего едока на финальном рывке к полюсу), но проблема оказалась с расходом калорий. Британцы тратили в среднем 5500 калорий на тысячу калорий больше норвежцев, потому что тащили всё на себе. Теперь представьте, что это происходит каждый день. Люди слабели на глазах, организм восполнял недостаток калорий за счёт мышечной массы.

4. Промежуточные склады
Каждая экспедиция устроила склады с едой и горючим по своему маршруту.

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



В итоге англичанам приходилось тратить лишние силы, чтобы найти свои собственные припасы.

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

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

У Амундсена с этим ситуация оказалась получше.
Исследователи в 1929 году нашли канистру норвежцев керосин там ещё присутствовал.

6. Планирование впритык.
Амундсен при расчёте маршрута оставлял каждый четвёртый день на отдых. Чтобы группа могла просто остаться в палатках и целый день восстанавливаться.
Это пригодилось им при восхождении на ледник Акселя, когда попали в жуткую пургу и продвижение замедлилось. График в итоге не был нарушен, еды хватало.

Скотт не допускал в расчётах случайностей и задержек, не оставил никакого запаса по времени.
Он постоянно говорил: Мы не можем позволить себе задержку. Готовя четырёхмесячное путешествие, он не заложил в свои планы возможность плохой погоды даже в течение четырёх дней. В худшем случае, как отметил Бауэрс в своём дневнике, задержка будет означать всего лишь небольшую нехватку провизии на обратном пути, но это мелочи. Мелочи! Это при их дефиците калорий!

Итого: при одинаковых начальных условиях одна группа выполнила свою задачу и вернулась домой, вторая героически погибла. Подробности гибели британской экспедиции трогают душу.
Эдгар Эванс получил травму головы от падения и через сутки умер.
Лоуренс Отс, когда понял, что не может больше идти и не хочет задерживать остальных, сказал: Я немного пройдусь и вернусь не скоро. Вышел из палатки без обуви и не вернулся.
Трое оставшихся шли столько, сколько позволяла погода. Зима наступила раньше обычного и оказалась гораздо суровее, чем можно было предполагать. Бауэрс и Уилсон умерли первыми, Скотт накрыл их одеялами, собрал дневники и письма, и умер сам.
Последней его записью было ради Бога, позаботьтесь о наших близких.

Дневники и письма были опубликованы, в Британии объявили сбор пожертвований.
Денег хватило на оплату долгов экспедиции и на пенсию близким погибших.
Скотт стал национальным героем.
Автор Питера Пена писал: Нет такого британца, который бы не почувствовал в эти дни прилив гордости, узнав из послания, написанного в палатке, на что способно его племя

Поминальную службу провели в соборе Святого Павла, на церемонии присутствовали все высшие чины Великобритании во главе с королём.

А Амундсена в Британии приняли со скандалом: президент Королевского Географического Общества Джордж Керзон произнёс двусмысленную речь. Амундсен описывал этот эпизод так:
Тщательно взвешивая слова, лорд Керзон обосновал приглашение меня в качестве докладчика, причём особо отметил то обстоятельство, что я приписываю часть нашего успеха собакам, после чего завершил свою речь словами: Посему предлагаю всем присутствующим грянуть троекратное ура в честь собак, да ещё подчеркнул саркастический и унизительный смысл своего высказывания успокоительным жестом в мою сторону...


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

Не стоит думать, что героическое раздолбайство это только британская черта. Буквально в следующем 1912 году пропало три русских арктических экспедиции и там не всё в порядке было с организацией. Время перечитать Двух капитанов кто всё-таки виноват в гибели экспедиции капитана Татаринова?

Берегите себя и выбирайте правильных руководителей.

Материалы по теме:
1. Собственно книга Хантфорда. У нас вышла под названием Покорение южного полюса. Гонка лидеров. Годится как настольная книга для менеджеров проектов.

2. Мини-сериал 1985 года по книге. Последнее место на Земле. В сериале засветились начинающие актёры Хью Грант и Билл Найи.

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

4. Статья на сайте birdinflight

5. Статья на Вархеде

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

Автор: Юрий Деточкин



VDS серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

И снова Notion и еже с ним

17.02.2021 10:06:07 | Автор: admin

Сегодня я решил поразмышлять на тему зачем нам это надо (на примере Notion)? Пост чистая философия.

Вообще, я к Notion не имею никаких претензий. Никто же не предъявляет претензии молотку Просто это первый сервис, который мне попался, который обладает огромным функционалом.

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

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

Начнем с простого. Книги, фильмы, музыка. Создал каталоги: что смотрел, что читал, что слушал, что планирую читать, смотреть, слушать. Даже какие-то рейтинги придумал, что понравилось, а что не очень, оценки от 0 до 5, нет до 10, так объективнее, теги по жанрам. Даже где-то писал комментарии.

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

Друзей оцифровал. Фото там, дни рождения, дни рождения детей, ссылки на соцсети, контакты Теги

Хобби, животные, машина, всё оцифровал, навешал тегов, добавил ссылок на ресурсы

Работа! Тоже все оцифровал по аналогии. Прям всё! В общем, всё по феншую.

Планы наше спасение и наша погибель. Notion помогает раздуть их до вселенских масштабов. Пришла в голову идея в планы ее, задачи к ней, подзадачи к ним, сроки каждой задаче/подзадаче, ответственных лиц и всё такое. Это все на волне эйфории от гениальности идеи. Чем она гениальнее мне казалась, тем больше места она занимала в Notion.

Что получил в итоге.

Сначала был вопрос а на хера мне всё вот это вот? Кому интересно, да и в принципе кто это увидит, что я читал, смотрел, слушал и как у меня всё это отсортировано? Все эти рейтинги для самого себя? Если мне понравился фильм, то на кинопоиске я поставил оценку и забыл про него. С книгами еще проще: прочитал удалил. Всё. Нет книги. Музыка. Вся она в яндексмузыке в подборке понравилось (и то, что-то удаляю, что-то добавляю). Всё. На хрена она в Notion?

Друзья. Все в телефонной книге. Кого забыл поздравить с днюхой - не обижайтесь.

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

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

И вот к каким выводам я пришел.

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

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

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

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

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

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

P.s. Есть такое понятие: создать википедию из своей жизни. Вот именно этим многие и пытаются заниматься благодаря этому сервису. Я никого не осуждаю. Ваша жизнь и вам ее жить.

А я не хочу, чтобы моя превратилась в 0 и 1.

Подробнее..

Какв Ozon пришли к релизам мобильных приложений раз в неделю

23.05.2021 16:04:26 | Автор: admin

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

С чем мы столкнулись, пока выпускали релизы по этой схеме:

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

  2. Долгоправитьбаги.Вкоде они могутбыть исправленыбыстро. А вотдо пользователейфиксдоходит уже вместе с той самой глобальной фичей.

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

  4. Долго релизить мелкие фичи. Какие-то улучшения могут занимать немного времени на разработку, но быть важными для пользователей и бизнеса. Точно так же, какисправления багов в пункте выше, для релиза они будут ждать того монстра, которого мы пилимтримесяца.

  5. Невыносимо долго проводить регрессионное тестирование. Всё,что было переделаноза несколько месяцев,мы будем проверять, чинить, перепроверять, чинить, перепроверятьНу, вы поняли

  6. Многохотфиксов. Чем больше число и объем изменений, тем сложнеебудет найти все баги перед релизом. Вот и появляютсяхотфиксы. Ещёза такой долгий срок разработки может прилететь какая-то очень срочная фича, ждать нельзя надо срочно выпускать(например, поддержать разрешение на отслеживание или добавить что-то по срочному рекламному контракту).

Проблеммного,и они все значимые. Когда бизнеспришёл к нам и сказал, что надо релизить быстрее мы уже ожидали этого. Но не ожидали, что они скажут: Релизьте раз в неделю.

Мы в шоке, как это реализоватьнепонятно.Мы в шоке, как это реализоватьнепонятно.

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

Сокращаем время выпуска релиза: первая попытка

Решили, что надодвигаться к целиитерационно.

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

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

Параллельно решили начать писатьавтотесты. Ну, как начать. У нас и до этого они были, но пользы не ощущалось. Поняли, что пора их встраивать в процессы.

Идёт первый месяц. Работаем. Пилим фичи, тестируем. Все заряжены.Но в итоге получили: тотобъём работ, который запланировали разработать за три недели, закончили под конецчетвёртой. Стали искать, где же выиграть время,нашли только один варианттестирование. Как могли, сократили регресс, но всёравно нашлинесколько критичных багов. В итогев зависимости от платформы с релизом опоздали на неделю-полторы.

Вторая попытка: нужно что-то менять

Да, мы решили, что нужны изменения. Но поменяли не процессы, а... сроки. Раз тяжело планировать на месяц давайте запланируем релизчерездве недели! Меньше успеем сделать фичей, быстрее проведем регрессионное тестирование - проще будет запланировать объем работ.

Тем временемтестировщикипродолжают писатьавтотесты

Пробуем всёравно каждый раз не успеваем.

Стали анализировать,из-за чегоне выходит уложиться в срок:

  1. Неправильно оцениваем время на разработку.

  2. Блочимсябекендом от этого тормозится и разработка, и тестирование.

  3. Продактыпоздно вносятпоследниеправки в ТЗ.

  4. Не учитываем время на починкубагов.

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

И тут пришлиQA.Сказали, что при двухнедельных релизахскоупнеособосократился.

Разработчиков много, они разделены по разномуфункционалуи задвенедели успеваютнакомититьпрактически во все компоненты. Стало понятно, что несмотря на то, что мыНИ РАЗУне успели в срок ни при месячном релизе, ни при двухнедельных пора двигаться дальше.

Недельные релизымыидём к вам!

Прежде всего надо было составить календарь наших действий на неделю. По разработке получилось так:

Понедельник

Релизная ветка

Вторник

Фичи

Среда

Фичи

Четверг

Фичи

Пятница

Фиксы багов

Фичиуходятвсвои фича-ветки. И когда она полностью сделана, проверена, принятапродактом, тогда уже попадает вdevelop.

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

Получается, что где-то в среду-четверг должен начаться процентныйроллаутприложения.

Меняемся в тестировании

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

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

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

  1. Дизайн;

  2. Бекенд;

  3. Контракт.

Если чего-то из этого нет смысла братьфичув разработку на мобильной платформе тоже нет.

Дальше встал вопрос о том, когда же можно включатьфичув релиз. Получились такие правила:

  1. Бекендфичидолжен быть напродакшене.

  2. К началурелизноготестирования нет критичныхбагов(ни на фронте, ни набекенде).

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

Меняемся в разработке

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

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

Тикетавтоматом двигается по статусам. Запушилкоммит перешел вinprogress.Создалmergerequest перешел вcodereview.ПрошелreviewпопалвQA.

Втикетеавтоматически проставляется версия релиза, куда он попал и номербилда.

По каждой сборке запускаютсяUI-автотестыпозатронутомуфункционалу.Это тоже определяется самопо измененным файлам вmergerequest.В результате репорт попадаетвкомментарийтикета вJira.

Дажеmergerequestна влитие эпика вdevсоздаётсяпросто по принятию продактом фичивJira.Если нет конфликтов, то и вливается сам.Релиз сам закрывается, а новый самсоздаётся.

QA Notes

Ещёмы ввели требования к разработчикам писатьQANotes.Там указывается:

  1. Что было сделано.

  2. Что могло быть задето.

  3. Приложены скриншоты или видео.

  4. На какой среде удалось проверить.

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

QANotesпозволили значительно ускоритьтестированиеиревьюкода. А ещёдали нам скрытый бонус:пропалиреопеныотQAиз-закрешейна старте.

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

Автотестыраньше находят баги. Теперь не надо ждатьрелизноготестирования, чтобы увидеть проблемы после интеграции. Прогоныавтотестовпроисходят после каждоговливания эпика вdev,а такжекаждуюночь. Еслинадо, то можно запустить на эпик-веткедо вливания вdev. Раньше нашли баг раньше исправили.

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

А еще добавиласьротируемаяроль QAза релиз.Этоттестировщикгде-то раз вдватримесяцаделаетповторяющиесявещи:

  1. Составляет наборрелизныхтестов.

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

  3. Напоминаеттестировщикампосмотретьотчёты поавтотестамнарелизномбилде.

  4. Пушитпересборкурелиз-кандидатов, если что-то добавилось.

  5. После релиза неделюмониторитпаденияи отвечает на запросы поддержки.

В автоматизацию тестирования мы добавили не только проверкифункционала, но и аналитику, отправляемую приложением.

Автоматизация помогает контролировать стабильность среды с помощью выполнения тестов после изменения кода приложения:

Мы также проверяем, что новыеавтотестыне ломают существующие:

Новая схема релиза мобильных приложений

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

Теперь мы спокойнее переносимфичи. Неприятно, когда не успели, но перенос выхода фичи на неделю воспринимается спокойнее, чем на более долгий срок.

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

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

Какиеестьсложности

В первую очередь этонепростойрефакторинг. Когдавмерживодинкоммит, вам надо перепроверить всёприложение.Сейчас мы прежде всеговливаемтакое по понедельникам-вторникам, чтобырефакторингмаксимально настоялся вdev, накрутилсяавтотестамии был потроган при тестированиифичей.

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

Что ещёможно улучшить

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

Ещёмы никогда не останавливаемся в автоматизации процессов. Постоянно находим возможность убрать ручную рутину. И покрываемавтотестамивсёбольшефункционала.

Для себя мы выработали такие шаги, на которые надо пойти, чтобы завести у себя релизы раз в неделю:

  1. Строгие требования к готовностифичи.

  2. Приоритет напереоткрытыхтикетах.

  3. Весь функционалзакрытфичефлагами.

  4. Строгое расписание релизов.

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

Подробнее..

Мы решили внедрить Agile-Lean принципы в процесс разработки на ходу и вот что из этого получилось

19.06.2021 12:05:20 | Автор: admin

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

  1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

  2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

  3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

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

  2. Scrum-мастер обычно тимлид группы разработки, занимается управлением процесса разработки, несет ответственность за конечный результат работы разработчиков.

  3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

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

Совещания:

  1. Ежедневный митинг команды.

  2. Ретроспектива в конце спринта.

  3. Ежеквартальные ретроспективы.

Параметры спринта:

  1. Продолжительность: 1 месяц.

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

Данный подход использовался на большинстве проектов, динамика при использовании была положительная.

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

Хьюстон, у нас проблемы

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

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

  1. Сильный перегруз разработчиков. Стабильное превышение 8-часового рабочего дня, выход на работу в выходные. Снижена мотивация, нарастает напряжение в команде.

  2. Недостаточное качество итогового кода, требуется повысить контроль качества.

  3. Много задач возвращается на доработку, в процессе тестирования выявляются не зафиксированные требования в описании задачи. Необходимо улучшить описание требований.

  4. Разные направления работ выполняют разные группы разработчиков, недостаточно взаимодействия по реализованной функциональности. Необходимо отказаться от разделения.

  5. Много времени уходит на разработку и доработку, консультанты простаивают.

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

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

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

Основываясь на описании бережливого производства, можно выделить не только сильные, но и слабые стороны для бережливой разработки.

Сильные стороны:

  1. Получение результата в ограниченное время.

  2. Устранение ненужных действий, которые могут снизить стоимость.

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

  4. Гибкость проекта, возможность его корректировки под требования заказчика.

Слабые стороны:

  1. Большие требования к вовлеченности команды в процесс.

  2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

  3. Необходимость детального планирования перед каждым спринтом.

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

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

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

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

  • Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя: излишняя функциональность; ожидание (паузы) в процессе разработки; нечеткие требования; бюрократизация; медленное внутреннее сообщение.

  • Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

  • Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.

  • Предельно быстрая доставка заказчику. Короткие итерации.

  • Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.

  • Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

  • Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

Проанализировав принципы, сформировали 7 своих, которые подошли к нашей текущей ситуации и должны были помочь закрыть существующие проблемы:

1. Убрать ненужное

Под ненужным будем понимать следующее:

  1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

  2. Ненужный код, дублирование кода.

  3. Нечеткие цели и требования. Если есть такие задачи, то их отправляем на проработку и исключаем из Backlog. После детальной проработки задача может быть снова помещена в Backlog.

  4. Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.

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

Что мы сделали, чтобы решить задачу:

  1. Детальная проработка требований и согласование описания требований с тимлидом разработки, дополнительная расшифровка требований тимлидом на понятный для разработчиков язык.

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

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

  4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

Процесс разработки сам по себе порождает новые знания, которые необходимо зафиксировать и распространить. Было решено для каждой задачи выделять дополнительное время на проектирование, чтобы разработчик успел детально зафиксировать вносимые изменения.

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

3. Повышение качества кода

Любые дефекты, несоответствия полученной функциональности требованиям появляются, когда код не проходит достаточную проверку качества.

Для повышения качества были приняты следующие предложения:

  1. Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.

  2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

  3. Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

  1. Спринт длится 1 рабочую неделю.

  2. На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.

  3. Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).

  4. Публикация на продуктивный стенд выполняется только один раз в последний день спринта.

  5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

Данный принцип основывается на том, что все участники команды проекта должны уважать друг друга. Когда дела идут плохо или не по плану, необходимо сосредоточить внимание на выявлении пробелов в рабочем процессе, которые могут приводить к конфликтам и проблемам. Мнение каждого участника процесса важно и должно быть принято во внимание другими участниками процесса.

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

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

6. Не торопиться с принятием решений

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

Решение принятое под воздействием эмоций может породить к большому числу проблем.

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

  1. Организует периодическое обучение, разбор сложных ситуаций.

  2. Инициирует передачу опыта между разработчиками.

  3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

  4. Занимается развитием разработчиков и расширением их компетенций.

  5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

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

Основная проблема бережливого производства отодвигание сроков

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

Нельзя забывать, что проект имеет определенные сроки, превышение которых может привести как к штрафным санкциям, так и к разрыву контракта. Это необходимо учитывать, если вы планируете внедрять Lean в текущий проект.

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

Итоги

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

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

Но в любом случае необходимо взрастить эксперта среди ваших сотрудников. Он будет сосредоточен на улучшении процесса разработки и мотивирован в повышении своих навыков и навыков команды разработки.

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

  1. Обеспечить единую общую среду общения и обмена знаниями.

  2. Организовывать совместные видеоконференции, желательно с камерой, чтобы видеть эмоции участников.

  3. Не пренебрегать неформальным общением.

Немаловажно обеспечивать канал связи между командой разработки и командой внедрения со стороны заказчика. Заказчику необходимо понимать ваш процесс разработки и публикации, понимать сроки реализации требований. Для клиента важны и качество и скорость разработки, поэтому необходимо находить с ним точки соприкосновения, совместно планировать предстоящий спринт.

По итогам внедрения Lean получили следующие количественные изменения:

  1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

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

  3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

  4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

  5. Втрое уменьшилось количество дефектов, фиксируемых конечными пользователями.

Данный опыт планируется транслировать на другие проекты компании.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Подробнее..

Как работать с неизвестностью и неопределенностью в разработке

19.12.2020 12:08:03 | Автор: admin

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".

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

Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.

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

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

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

Неопределенности технических продуктов

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

В RankScience, где мы делаем платформу для непрерывной оптимизации и CDN для SEO вебсайтов, мы сталкиваемся с довольно большим количеством технических неопределенностей неудивительно, учитывая, что мы занимаемся тем, чего ещё никогда не было.

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

Основа нашей системы это три техники, пришедшие из Agile/Scrum:

  1. Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.

  2. Спайк. Простая реализация на коленке, которая позже будет выброшена, но поможет понять область проблемы.

  3. Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.

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

Эта методология помогает нам решать задачи, пока классическая система требует собственного обслуживания:

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

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

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

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

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

Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.

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

1. Анализ

Начинайте с проведения анализа если:

  • У вас есть проблема

  • Вы не знаете как её решить

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

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

Плюсы и минусы должны быть основаны на технических факторах типа:

  • Насколько трудоёмкая будет реализация

  • Насколько дорого это выйдет

  • Сколько времени потребуется

  • Какой гибкости мы лишаемся, принимая именно это решение

  • Насколько этим удобно будет пользоваться

Под разные команды значимость тех или иных факторов может быть разная.

В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:

  • Наша операционная нагрузка

  • Наш автобусный фактор

  • Скорость нашей команды

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

Одним из распространенных результатов анализа это документация типа такой:


Repository: плюсы и минусы

  • Плюсы

    • Это эффективный способ предоставлять доступ большомуобъему данных: записал один раз и читаешь отовсюду

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

    • Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных

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

  • Минусы

    • Подсистемы должны работать с общей схемой, что может влиять на производительность

    • Эволюция данных: "дорого" принимать новую модель данных,потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать

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

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


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

2. Spike

Спайк нужен, когда:

  • У вас есть проблема

  • У вас есть хоть какая-то идея как её решить

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

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

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

Хороший пример это бумажный прототип.

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

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

3. Трассер

Трассирующая пуля, трассер это боевой припас особой конструкции, который оставляет луч света в полёте. В разработке трассер это техника для ситуаций, когда:

  • У вас есть проблема

  • У вас есть решение, но вы не знаете как много времени это займет.

Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:

  • очень небольшое

  • запускается в продакшен окружении

  • остается, а не выбрасывается

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

  • успешно получает текст из поля ввода

  • отправляет этот текст в Segment

  • идёт в customer.io из Segment

  • обновляет список для рассылки

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

Трассер это не конечный продукт, а нечто, что более приближено к готовому, нежели спайк, который почти всегда должен идти на выброс, когда мы получили всю необходимую информацию.

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

Цикл Анализ Спайк Трассер

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"

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

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

Благодарю Антона Сметанина @dizzy_dalvin за помощь в редактуре

Подробнее..

Перевод Как работать с неизвестностью и неопределенностью в разработке

19.12.2020 14:20:36 | Автор: admin

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".

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

Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.

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

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

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

Неопределенности технических продуктов

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

В RankScience, где мы делаем платформу для непрерывной оптимизации и CDN для SEO вебсайтов, мы сталкиваемся с довольно большим количеством технических неопределенностей неудивительно, учитывая, что мы занимаемся тем, чего ещё никогда не было.

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

Основа нашей системы это три техники, пришедшие из Agile/Scrum:

  1. Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.

  2. Спайк. Простая реализация на коленке, которая позже будет выброшена, но поможет понять область проблемы.

  3. Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.

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

Эта методология помогает нам решать задачи, пока классическая система требует собственного обслуживания:

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

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

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

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

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

Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.

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

1. Анализ

Начинайте с проведения анализа если:

  • У вас есть проблема

  • Вы не знаете как её решить

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

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

Плюсы и минусы должны быть основаны на технических факторах типа:

  • Насколько трудоёмкая будет реализация

  • Насколько дорого это выйдет

  • Сколько времени потребуется

  • Какой гибкости мы лишаемся, принимая именно это решение

  • Насколько этим удобно будет пользоваться

Под разные команды значимость тех или иных факторов может быть разная.

В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:

  • Наша операционная нагрузка

  • Наш автобусный фактор

  • Скорость нашей команды

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

Одним из распространенных результатов анализа это документация типа такой:


Repository: плюсы и минусы

  • Плюсы

    • Это эффективный способ предоставлять доступ большомуобъему данных: записал один раз и читаешь отовсюду

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

    • Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных

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

  • Минусы

    • Подсистемы должны работать с общей схемой, что может влиять на производительность

    • Эволюция данных: "дорого" принимать новую модель данных,потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать

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

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


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

2. Spike

Спайк нужен, когда:

  • У вас есть проблема

  • У вас есть хоть какая-то идея как её решить

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

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

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

Хороший пример это бумажный прототип.

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

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

3. Трассер

Трассирующая пуля, трассер это боевой припас особой конструкции, который оставляет луч света в полёте. В разработке трассер это техника для ситуаций, когда:

  • У вас есть проблема

  • У вас есть решение, но вы не знаете как много времени это займет.

Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:

  • очень небольшое

  • запускается в продакшен окружении

  • остается, а не выбрасывается

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

  • успешно получает текст из поля ввода

  • отправляет этот текст в Segment

  • идёт в customer.io из Segment

  • обновляет список для рассылки

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

Трассер это не конечный продукт, а нечто, что более приближено к готовому, нежели спайк, который почти всегда должен идти на выброс, когда мы получили всю необходимую информацию.

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

Цикл Анализ Спайк Трассер

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"

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

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

Подробнее..

Гибкое управление бизнес-процессами и роль информационных систем

20.02.2021 18:04:03 | Автор: admin

Приветствую, Хабр!

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

Проблемы традиционного взгляда на бизнес-процессы

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

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

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

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

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

Гибкое управление бизнес-процессами

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

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

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

Есть такой термин как Adaptive Case Management. Его еще называют Agile BPM. Суть метода как раз описывает внедрение изменений в задачи на основе полученного опыта, где кейсы это ситуации, с которыми компания сталкивались в прошлом. Если проблема была решена успешно, то оставляем последовательность задач как было. Если проблема была решена плохо, то вносим коррективы и в следующий раз используем другой алгоритм.

Информационные системы и гибкое управление процессами

Когда нарастание сложности компании превращается в корпоративный хаос, менеджеры задумываются о внедрении инструментов, чтобы удержать контроль над системой. И здесь на помощь руководителям призваны различные информационные системы. Причём не важно, идет ли речь об ERP, BI, BPM, CRM, обычные таблицы любой класс этих продуктов для большинства менеджеров разновидность учёта и контроля качества бизнес-процессов. Где-то менеджеры контролируют движение денежных потоков. Где-то контролируют входящий клиентский поток. Где-то контролируют работ, которые выполняют сотрудники.

В гибком управлении процессами информационная система в большей степени не инструмент учёта управленца, а прежде всего инструмент для удобного взаимодействия сотрудников, где они могут сами организовать планирование и учёт в том виде, в котором это удобно для выполнения работы. Это когда-то давно поняли японцы, создавшие для координации и управления целыми заводами простые канбан доски. Сегодня это понимают разработчики таких инструментов как Trello, Airtable, Miro, Notion, Slack, Unicore и других сервисов...на первый взгляд, между этими системами мало чего общего. Но, по-моему, все они решают одну большую проблему предприятий отсутствие общего, удобного и адаптируемого информационного пространства для совместного решения задач бизнеса.

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

Относительно недавно появился термин Work Management System то, о чём я пишу об этом. Софт становится человекоориентированным и гибким, чтобы с помощью него не менеджеры управляли процессами, а сами сотрудники.

Подробнее..

Работа с вовлеченными сотрудниками как этого добиться? Часть 2

09.11.2020 12:16:47 | Автор: admin
В продолжении предыдущей статьи, расскажу о других мотиваторах для вовлеченных сотрудников.
Поощрение инициативы.
По данным Рамблера (news.rambler.ru/) треть россиян считают инициативу наказуемой.
Сотрудники не должны бояться высказывать свою точку зрения, проявляя инициативу, они показывают свое неравнодушие к Компании. Нужно дать им понять, что инициатива не только не наказуема, но и будет поощряться.
Интерес к работе
Каждый специалист должен чувствовать себя на своем месте, должен понимать свою роль в Команде, ее значение, и вклад, который может принести своим трудом. Как этого добиться?
В первую очередь, на этапе адаптации, нужно дать сотруднику максимально полное понимание целей и задач Компании. К чему мы идем, какая у нас миссия. На этапе формирования у специалиста мотивации, мы можем повысить его вовлеченность в задачи бизнеса, советуясь с ним, принимая его предложения, если они направлены на улучшение процессов и прочее. Сотрудник должен знать, что его мнение ценится, и, тогда он становиться вовлеченным.
Мотивационные беседы с сотрудниками.
Проводите мотивационные беседы честные разговоры со своими сотрудниками. Выясняйте, как каждый себя видит в этой компании, как оценивает свои возможности, как представляет свои точки роста, слабые и сильные стороны, куда бы он хотел двигаться, что попробовать в этой самой ситуации всеобщей неопределенности. Оптимально такие беседы проводить 4-7 раз в год, с каждым сотрудником.

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

Очень важно сосредоточиться именно на вовлеченных сотрудниках, сделать их максимально эффективными.

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

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

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

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
Подписывайтесь! Далее будет
Подробнее..

Смена профессии. Путь из никуда в QA

22.02.2021 16:14:10 | Автор: admin

Когда пора увольняться

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

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

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

Принимаем решение

Ok, наверное надо что-то менять, найти новую работу и уйти со старой. Но как решиться, если одолевают сомнения, а перемены вызывают не очень приятные чувства?

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

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

Условия созданы, начинай действовать - работай, учись, ищи. Не бойся удлиннить свой путь, разбить на этапы; достигай промежуточных выгод. Ошибки быть не может, ты бьешь точно в цель, получаешь выгоды уже в процессе. Теперь уже и решаться не надо.
Когда будешь готов, уходи.

Первые шаги

Предположим, ты принял решение всё поменять. На старой работе очевидно перспектив никаких, ты начал смотреть по сторонам. Возможно в сторону IT. Возможно даже, в сторону QA. Тогда продолжим.

Нам понадобится:

  1. Определить цель. Зачем это всё. Куда хотим прийти, в какую сторону расти и как развиваться.

  2. План составить, сроки определить. Время на всё это дело заложить.

  3. Начать учиться. Можно самостоятельно, можно где-то или с кем-то, тут кто как больше любит.

  4. Вступить в профессиональные сообщества. Общаться, задавать вопросы, интересоваться.

  5. Поглядывать на рынок. Прицениваться, описание вакансий смотреть, про компании читать.

  6. Готовить резюме. Тут с ходу не разберёшься - постепенно корректируя детали, добавляя полезное, удаляя лишнее, доводить до совершенства.

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

Цель

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

А дальше, целеполагание.

- Какую проблему ты решаешь?
- Почему ты хочешь решить проблему таким способом?
- Сколько часов в день ты готов выделять?
- Когда решится проблема?

Ну хорошо, проблема решилась, зарплата выше, коллектив хороший, работа удалённая и развиваться дают.
А куда развиваться?
Зачем всё это?
Может менеджером стать или в код погрузиться. Стартап запустить.
Может эмигрировать?
Чего ты хочешь достичь через год? Два года? Пять лет? Десять? Надо знать. Сразу.

И подчинить главной цели все остальные.
Тогда сразу понятно будет зачем всё. И вопроса такого не встанет. Любое событие, любое действие или отдаляет от цели или приближает к ней.
Наметь дату. Определи критерии. Составь план. И вот уже цель стала ближе. Осталось немного.

План

Так, давай посмотрим: цель есть, мотивация есть, теперь надо что-то делать, планировать. Нарисуем дорожную карту, определим, где находимся на данный момент, какими ресурсами располагаем, какими инструментами будем пользоваться. Что будет происходить, когда и сколько времени займёт. Мы знаем, где хотим оказаться в конце и все остановки планируем в соответствии с этим, все повороты подчиняем одному направлению. Не забываем периодически себя вознаграждать.

Ну например, цель - эмиграция. Куда, зачем, как - отдельная история. Что у нас имеется? Профильное образование или нет? Уровень языка? Возраст? Средства? Бэкграунд какой? Предположим, как вариант - эмиграция по работе. Тогда первая работа может быть любая, вторая - желательно на зарубежную компанию. 2-3 года релевантного опыта надо как минимум, за это время много чего может произойти (оставляем место для спонтанности в жизни), но помним - всё это время мы занимаемся эмиграцией: учим язык, получаем образование, откладываем деньги, налаживаем связи и не забываем про другие способы поехать.

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

Обучение

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

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

Ты прошел хороший онлайн курс, готовишь резюме, читаешь профессиональные статьи, самонадеян и рвешься в бой. Готов ли ты уже работать? Рано ещё.

Ты вступил в профессиональные сообщества, выполняешь практические задания, берёшь учебные проекты, анализируешь рынок, уже можешь поспорить с кем-то из твоей будущей сферы деятельности. Готов ли ты сейчас? Рано ещё.

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

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

Нет предела ступеням мастерства.
Но нужно начать идти.

Сообщества

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

Ты и так сделал всё, что мог, не твоя вина, что не получилось. Что важнее: преуспеть или чтобы не было твоей вины в неудаче?

Необходимо чётко определить, что от тебя зависит, а что не зависит; идти по пути и не искать оправданий. Ты или сделал всё, что нужно, или нет.

Подготовил резюме? Даже отправил в пару мест? Никто не зовёт? Проблема.

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

Резюме

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

Зачем вообще нужно резюме?
Оно должно продавать. Тебя должны звать на интервью, если же нет - всё плохо, как бы ты не оправдывался, если собеседований нет - твоё резюме пробило дно.

Что делать?

1. Формат
Красивое оригинальное оформление поможет поможет, если ты хочешь быть например дизайнером - тебя как раз не позовут в тестирование и придётся поискать что-то ещё. Если всё таки в QA - делай нормальное консервативное резюме формата самых больших площадок вакансий.

2. Фотка.
Выбери нормальную фотку, без комментариев.

3. Позиция.
Как тебя будут искать, так ты и должен писать название искомой должности. И не надо писать, что ты Junior, это я как работодатель там сам разберусь. Ты - специалист.

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

5. Навыки и пройденные курсы.
Всё, что знаешь, попробуй сделать на практике. Скачай, устнови, используй, зарегистрируйся - напиши всё, что теперь умеешь. Курсы, книги, сайты - укажи все ресурсы, где ты учился.

6. Обо мне.
Напиши почему ты здесь. Напиши почему именно ты. Напиши так, что бы я поверил.

И теперь открой своё резюме всем. Обновляй каждый день. Откликайся на всё. Рассылай всем. Каждый день.

Интервью

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

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

Не про тебя? Рассылаешь резюме со скоростью 100 штук в секунду? Интервью распланированы на недели вперед? Супер!
Получил отказ, второй, третий, пятый? Превосходно. Ты всё ближе к заветной работе!

Ты грамотно планируешь время собеседований, готовишься к каждому, узнаешь про компанию, у тебя появляются вопросы.
Ты внимательно слушаешь на интервью, записываешь, что спрашивают. Ты вообще, всегда всё записываешь.
Снова отказ? Грустно? Нет конечно. Это твой звездный час, ты теперь точно знаешь, что делать! Что ещё учить, какие вопросы задавать, какие задачи решать, о чем говорить.

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

И вот тебе сделали оффер. Ты же этого хотел?
Тогда начни уже ходить на собеседования.

Страхи

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

Куда ты поехал, кому ты там нужен?
А связи-то есть? Нет. Ну и на что ты рассчитываешь?
Денег нужен запас, без этого никак.
И вообще у тебя долги - разберись сначала. Да и не время сейчас, времена трудные, может быть позже, но вряд ли.

Это сложная работа, надо быть очень умным, ты не сможешь. Ты там будешь лишним. Может, если будешь долго и усиленно учиться - возможно, но когда? Столько дел.

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

У тебя никогда ничего не получится.

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

У них были те же сомнения, такие же страхи, похожие проблемы, как у тебя.
Они смогли, сможешь и ты.

Каждый, кто захотел, каждый, кто начал идти, кто проделал работу, каждый кто освоил, кто получил оффер - каждый достоин.

Ты не можешь только одно.
Ты не можешь не идти по пути.
Так иди же!

Подробнее..

Более 10лет ставлю цели на год рассказываю, как это делать эффективно

04.01.2021 22:21:38 | Автор: admin

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

Я полностью прошёл все стадии грехопадения: в студенческие годы искал сакральные ответы в стопках self-help макулатуры; затем разочаровался и решил, что весь этот успешный успех это разводилово для дурачков (до сих пор уверен, что Наполеон Хилл шизофреник); позже переосмыслил всё ещё раз и пришёл к своему пониманию того, как может выглядеть саморазвитие с адекватным лицом.

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

Зачем ставить цели

Любой уважающий себя инфоцыганин тонироббинсового разлива обязательно будет топить за магическую силу целей. Учёные ведь доказали, что 3% студентов Йеля с записанными целями спустя 20 лет оказались богаче оставшихся 97% вместе взятых! (На самом деле,конечно нет.)

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

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

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

Многие из вас наверняка сталкивались с такой ситуацией: задачи по работе успешно выполняются в срок, а более личные задачи благополучно откладываются на завтра, кочуя изо дня в день по туду-листам. Почему так происходит? Рабочие задачи имеют соответствующий обвес в виде дедлайнов, системы контроля за их исполнением, и обратной связи по результатам. Если за личными устремлениями не стоит аналогичной системы то неудивительно, что они часто проигрывают в битве приоритетов.

В общем, попробовав разные варианты, я для себя сделал вывод с целями всё-таки получается более результативно, как ни крути.

Сферы жизни

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

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

Для себя я выделил пять основных сфер жизни (подробнее о том, почему именно эти пять, и как они связаны с пирамидой Маслоу, я писалв этой статье).

Пирамида МаслоуПирамида Маслоу

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

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

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

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

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

Как я ставлю цели на год

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

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

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

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

Фрагмент из моего годового отчётаФрагмент из моего годового отчёта

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

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

На мой взгляд, лучше поставить 15 целей и достигнуть 70% из них, чем на 100% выполнить три цели.

Но при этом, все цели не обязательно должны быть одинаковыми по важности. Каждый год я выбираю одну какую-то сферу обычно это та область, где давно не было значимого прогресса и ставлю в ней одну главную цель года. Эта цель должна быть реально крутая я описываю её для себя какЧто должно произойти в течение года, чтобы даже если всё остальное пойдёт наперекосяк я всё равно останусь дико доволен и посчитаю, что год удался?Это достаточно жёсткий критерий, поэтому главной целью оказываются почти всегда какие-то прорывные для моей жизни амбиции.

Соответственно, в течение года я каждый день оказываю этой альфа-цели первостепенное внимание: до того, как переходить к другим вещам, я всегда спрашиваю себя а что я сделал для главной цели? Если ответ ничего, то заниматься другими вещами рано, надо сначала хоть как-то продвинуться в направлении самой козырной цели. Такой фокус позволяет мне быть уверенным, что самое важное для меня не окажется в составе тех 30% нереализованных целей. Именно через принцип главной цели на год я в своё время купил квартиру, сменил карьеру и переехал в Москву, поднял уровень доходов в несколько раз, начал ходить в тренажёрный зал и набрал 15 кг, встретил свою спутницу жизни.

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

Расскажу на примере: можно поставить себе цель хочу накачаться как Арни, и жать соточку от груди через год. Проблема в том, что результат при такой формулировке находится уж очень далеко от стартовой точки (особенно если вы такой же худосочный нёрд, как я), и поддерживать должный уровень мотивации, страдая месяцами в зале и всё ещё видимо не приближаясь к конечной цели, довольно сложно.

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

Цели поставлены, что дальше?

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

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

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

Фрагмент моего ежедневного чеклиста (текст внутри ячеек я удалил там слишком личная информация)Фрагмент моего ежедневного чеклиста (текст внутри ячеек я удалил там слишком личная информация)

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

Такой подход позволяет мне не забивать на те цели, которые я сам для себя поставил в начале года.Достаточно трудно 365 раз в году каждый день писать в специальной колонке сегодня я опять ничего сделал для этой цели рано или поздно приходится идти уже что-то делать, иначе стыдновато перед самим собой.

Мне часто говорят, что такой подход с чеклистами это какое-то извращение, и нормальные люди так не живут. Многие из этих людей, как ни странно, не видят ничего плохого в том, чтобы заниматься прокачкой какого-нибудь орка в World of Warcraft и радоваться растущим циферкам его характеристик.

На мой взгляд, прокачивать своего персонажа в жизни гораздо полезнее и интереснее, чем в игре.

Лайфхаки в достижении целей

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

Agile-подход

Мне очень нравятся два принципа из философии Agile, они отлично работают не только в разработке программных продуктов, но и для личных проектов (подробнее писал об этомздесь):

  • Bias for Action(склонность к действию). Если ты собираешься попробовать что-то новое, то не трать кучу времени на скрупулезное изучение вопроса и подготовку идеального плана. Лучше вместо этого начни с конкретных действий, на практике приближающих тебя к конечной цели: начни ходить в зал, запишись на курсы программирования, познакомься с владельцем бизнеса и обсуди с ним свою идею. Разобраться в нюансах и составить толковый план будет гораздо проще по ходу, чем теоретизируя на диване.

  • Minimum Viable Product(минимально жизнеспособный продукт). Не пытайся сразу же сделать идеально такая высокая планка обычно труднодостижима, и ты гарантированно будешь буксовать, пытаясь её осилить. Лучше подходить к вопросу поэтапно сначала реализуй минимально допустимое решение (которое, тем не менее, будет хоть как-то работать), а потом можешь его постепенно улучшать. Это гораздо легче, чем пытаться сразу сделать идеально; более того, в процессе поэтапного улучшения может оказаться, что идеал и не нужен приближения к нему на 7080% вполне может оказаться достаточно (по принципу Парето).

Микро-шаги

Этот принцип несколько перекликается с предыдущими. Чтобы поменять свою жизнь, гораздо важнее регулярность и долгосрочная ориентация, а не какие-то разовые сверх-усилия. Обычно люди подходят к целям наоборот: если уж заниматься своим здоровьем то нужно обязательно начинать ходить в зал так, чтобы упахиваться там до потери человеческого облика и выползать на четвереньках, блюя в коридоре из последних сил. Надо ли говорить, что заставлять себя регулярно ходить на такие самоизнасилования несколько, кхм, сложновато?

Гораздо более разумно, на мой взгляд, начинать с малого пусть даже первое время это будет до смешного малое. Например, недельку можно хотя бы просто регулярно приходить в зал и не делать там ничего страшного, просто походить на дорожке. Как только привыкнете к ощущению, можно переходить к следующему этапу вводить какие-то лёгкие упражнения, и так далее. Через 10 лет вам будет совершенно неважно: начинали вы по хардкору, или втягивались постепенно в течение месяца. Единственное, что будет иметь значение это бросили вы или нет. Так вот, микро-шаги как раз помогают снизить вероятность преждевременного бросания.

Метод яростных наскоков

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

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

Getting Things Done

Долгое время я не пользовался никакими таск-менеджерами, задачи себе писал в бумажном ежедневнике или в своём Excel-файле, и считал известную систему Getting Things Done Дэвида Аллена замороченной ерундой, которая только усложняет жизнь. Но недавно тема GTD всплыла вразговоре с Гришей Мастридером, и оказалось, что мой подход к управлению временем и задачами на самом деле достаточно близок к этой концепции (если убрать всю олдскульную чепуху Аллена с десятками бумажных папочек).

Так что я пересел на приложение Todoist, внёс несколько поправок в свою систему в соответствии с заветами GTD и теперь весьма доволен результатом. Использовать специальное приложение для управления задачами оказалось гораздо более удобным.

Целеполагание здорового человека

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

Этот момент мы обсуждали недавно винтервью с Алексеем Марковым(автором Хулиномики) он мой метод целеполагания немного покритиковал, и рассказал об альтернативном подходе, который практикует он сам. Это более мягкий вариант, без жёстких целей и чрезмерно анального контроля более ориентированный на ценности, привычки и роли. Рекомендую послушать его рассказ возможно, такой вариант подойдёт вам больше. Надо только учесть, что к такому дзен-подходу Алексей пришёл уже после достижения финансовой независимости есть подозрение, что для максимально результативного стремления к амбициозным целям он приспособлен чуть меньше.

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

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

Подробнее..

Перевод Этому методу продуктивности больше 100 лет и он отлично работает метод Айви Ли

03.11.2020 12:06:29 | Автор: admin
Простому и действенному методу Айви Ли (The Ivy Lee Method) уже более ста лет и суть его по-прежнему заключается в одном элементарном, но эффективно работающем принципе концентрации на важном и умении ограничивать второстепенные задачи.

image

Ivy Lee (1877-1934) источник Wikipedia

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

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

Итак, что такое метод Айви Ли?


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

Мы решили показать использование метода Айви Ли на примере календаря Tweek и подробно описать, как это все реализовать на практике.

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

Правило 1


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

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

Правило 2


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

Последовательность помогает концентрации на чем-то одном и приучает к дисциплине.
Однозадачность ключ к результативности.

Правило 3


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

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

Правило 4


Повторяйте это ежедневно.

Пример метода Айви Ли



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

История метода Айви Ли



В начале XX века Айви Ли (Ivy Ledbetter Lee) был одним из самых влиятельных пионеров в области связей с общественностью в Америке, а также успешным бизнесменом. Он консультировал крупные промышленные корпорации, например, такие как Standard Oil семьи Рокфеллеров.

image

Ivy Ledbetter Lee, Charles Schwab источник Wikipedia

В это же время Чарльз Шваб (Charles Michael Schwab) являлся одним из богатейших людей в мире, которому принадлежала компания Bethlehem Steel Corporation (самая крупная корпорация по производству кораблей и вторая по производству стали в США). Стремясь увеличить продуктивность своей команды, он пригласил к себе в гости консультанта Айви Ли.

При встрече Шваб поставил ему единственную задачу: Покажи мне способ делать больше.
На что Ли ответил: Дайте мне 15 минут наедине с каждым из ваших топ-менеджеров.

За эти 15 минут Ли, как и обещал, объяснил каждому из руководителей компании свой метод. На вопрос Шваба об оплате, он ответил: Когда через три месяца вы увидите результат, выпишите мне чек на любую сумму.

Через три месяца Ли получил чек на сумму $25 000. Настолько Чарльз Шваб был удовлетворен прогрессом внутри своей компании и эффективностью этого простого метода. В наше время эта сумма эквивалентна почти полумиллиону долларов.

Источник: The Ivy Lee Method: The Daily Routine Experts Recommend for Peak Productivity

Примечание автора



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

  • Важное и срочное
  • Важное и несрочное
  • Неважное и срочное
  • Неважное и несрочное


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

Делайте каждый день самое важное.

Подробнее..

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

06.05.2021 10:07:53 | Автор: admin


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

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

Я тогда работал в стартапе; фронтенд-команда у нас состояла из троих человек, еще имелась бэкенд-команда таких же размеров. Мы работали над обновленной версией мобильного приложения и должны были уложиться с релизом до четко обозначенного дня. Одна проблема: этот день был произвольно выбран то ли простым директором, то ли техническим без каких-либо оснований для подобного решения.

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

Так или иначе, наша приблизительная оценка стала результатом двухдневных совещаний: сначала общий обзор новых функций, потом подробный разбор каждой в отдельности, потом еще более дробный анализ Наконец по каждому этапу работ прикинули количество часов, перепроверили, соотнесли с UX и UI-дизайном, всё сложили, накинули сколько-то часов сверху и вот получился срок выполнения работ.

Вы сейчас, наверное, подумали: ну, раз у них UX и UI-дизайны уже готовы, да еще и про запас часы заложены, то, наверное, всё должно пройти нормально? В большинстве случаев при установке сроков условия бывают похуже. Ну, в общем, нет. Нормально ничего не прошло.
Продолжительность работ была установлена в три-четыре недели не слишком много времени, если говорить о релизе нового продукта силами небольшой команды. Само собой, после первых двух недель мы уже стали отставать от графика. Не потому что медленно работали или мало часов тратили на проект, а потому что всё всегда идёт не по плану.

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

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

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

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

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

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

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

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

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

По моим прикидкам (статистику я не собирал, так что ручаться не могу), толк от этой переработки был только в краткосрочной перспективе. Ну да, выпустили приложение в срок. А следующий релиз уже пришлось задерживать, потому что многое переписывали. Разработчики были недовольны (и, как вы уже догадались, активно увольнялись), атмосфера в команде стала напряженной. И это мы еще не учитываем последствия багов, с которыми пользователи столкнулись после релиза.

Как нужно?


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

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

Recovery mode Прокрастинация или просто лень? Как различить и победить и то, и другое

26.05.2021 14:12:47 | Автор: admin

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

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

Психологическая природа состояний

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

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

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

Только и делай, что ничего не делай...Только и делай, что ничего не делай...

В книге Прокрастинация: первая помощь ирландские психологи Таня ван Эссен и Хенри Шувенбур выделили пять этапов на пути от официального старта работы над задачей до ее завершения, чтобы понять, в какой момент человеку мешает прокрастинация, а в какой лень:

A. Момент появления задачи;

B. Оптимальный момент для начала работы;

C. Момент, когда вы решаете начать работать;

D. Момент, когда вы принимаетесь за работу;

E. Дедлайн.

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

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

Основными причинами состояния лени педагоги называют несформированность механизмов саморегуляции и дефицит мотивации.

Французский психолог Альфред Бине, исследовавший лень еще в конце XIX века, выявил два ее типа:

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

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

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

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

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

А некоторые откладывают на потом саму жизньА некоторые откладывают на потом саму жизнь

На пути от принятия задачи к дедлайну, который описали Таня ван Эссен и Хенри Шувенбур, проблемы с прокрастинацией обычно возникают в промежутке между этапами С и D. То есть, человек уже решил начать работать, а сами активные действия откладывает. Задача стоит в плане и постоянно напоминает о себе.

Например, специалист ведет переговоры с новым клиентом. Договорились, что в течение 7 дней будут готовы аудит и коммерческое предложение. Будущий клиент ждет материалы в срок, а специалист понимает, что это важно: новый клиент принесет дополнительную прибыль. Он запланировал начало работы по этой задаче за 5 дней до дедлайна. Но проект масштабный, и аудит займет много времени. Да и текущих задач хватает: тут проверь ставки, там проанализируй запросы. А еще надо приготовить ужин, убраться в квартире, погулять с собакой. И так каждый день.

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

Читайте также 12 лайфхаков, которые помогут удержать клиентов в рекламном агентстве.

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

Чем похожи и чем отличаются прокрастинация и лень

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

У этих двух состояний действительно есть кое-что общее:

  • причины возникновения обеих проблем отчасти лежат в области мотивации;

  • результат схож: дела не делаются или делаются с опозданием;

  • негативные последствия, пусть и разные, есть и у лени, и у прокрастинации.

На этом со сходствами, пожалуй, все. Переходим к различиям.

Основные особенности. Их мы уже упомянули в предыдущем разделе:

Причины возникновения состояний. Хотя и у лени, и у прокрастинации они лежат в области мотивации, разница все же есть, и существенная. Сведем основные причины в сравнительную таблицу:

Последствия. Помимо психологических, которые мы приводили выше, и у лени, и у прокрастинации есть и другие.

Последствия лени отложены во времени. Человек может годами жить в таком состоянии и только потом понять, что из-за этого жизнь сложилась не так, как хотелось бы.

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

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

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

Или уже все?Или уже все?

Осознанность процесса и способность к прогнозированию. Тут механизмы лени и прокрастинации тоже работают немного по-разному.

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

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

Читайте также Топ-13 конструкторов чат-ботов для сайтов, мессенджеров и соцсетей.

Как победить лень и прокрастинацию

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

Как побороть лень

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

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

Зафиксируйте мотивацию письменно и держите перед глазамиЗафиксируйте мотивацию письменно и держите перед глазами

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

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

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

Теперь придется смотреть ;-)Теперь придется смотреть ;-)

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

Как взять прокрастинацию под контроль

Планирование. Да, планы и расписания помогают и прокрастинаторам. Только если для борьбы с ленью достаточно просто занести дело в план, для победы над прокрастинацией расписание лучше сделать жестким:

  • 9:0011:00 аудит для нового клиента;

  • 11:0016:00 текущие проекты;

  • 16:0018:00 обучение.

Примерно так, но еще более детально: заносите в план обед, перерывы, бытовые дела. Так пространства для маневра останется меньше.

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

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

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

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

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

Чтобы облегчить себе жизнь, формулируйте задачи четко и конкретно:

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

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

А вы ленитесь или прокрастинируете?

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

Подробнее..

Категории

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

  • Имя: Макс
    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