Продуктивная продуктивность

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

Начнем. Вечером мотивашка на всю: "Ух я завтра как дам, как всё успею". И тут, утро. Орет будильник, айфоновская мелодия "Радар". Вы ненавидите этот мир, что делать:

🌃 Спускайся на пол
Я с вечера стелю покрывало на пол или коврик для спорта. Единственное усилие, которое нужно сделать - это вывалиться из кровати на твердую поверхность. Почему? Внутренний диалог. Лежа в мякотке в сладкой темноте побороть железобетонные аргументы о дополнительных 10 минутах нереально. Можно вывалиться прям с одеялом, главное, чтобы было твердо. Это правильный мув. А вот неправильный мув - это врубить свет на всю, чтобы из глаз искры посыпались.
🌃 Бутылочку 0.3 животворящей
Также с вечера просто налить себе воды и поставить на тот же коврик. Когда ты доползешь до коврика, единственное что не будет вызывать отторжение - это вода. Можно с лимончиком. Это вторая хитрость, которая начинает вышибать из сна на уровне с твердым полом.
🌃 Дайте себе охренеть
Вы же проснулись, чтобы у вас было много времени. Вот у вас его навалом, дайте 10-15 минут потупить в темноту, приходит много разных интересных мыслей, а иногда вообще ничего не приходит и это тоже кайф. К этому моменту уже становится нормально и можно двигаться.

И окончательный гвоздь, но не обязательный — это прогулка. Вот тут наступает кайф, тишина, спокойствие, свобода, особенно летом. Но в зиму не работает, я проверял. Нет там кайфа в мороз)

Есть отягчающие обстоятельства:
✏️ желательно иметь 7 часов, т.е в 22:00 быть в постели, но если не получилось - встать все равно возможно;
✏️ холодно в квартире/доме. Спасает выползание вместе с одеялом, а рядом заготовить теплые вещи;
✏️ нет плана. Если делать нечего, то почти точно можно залипнуть в телефоне или уснуть, уткнувшись носом в коврик в позе младенца и пофиг, что твердо.
✏️ сопящая рядом вторая половинка. Увеличивает дальность до коврика вдвое, а значит и количество усилий. Также, увеличивает количество исторгаемого кайфового тепла. В студии на 38 кв.м. все, что написано выше - не работает либо нужно вставать в темень вместе)

Я пишу не про первый день, а про 14, 23, 35. То есть, не про мотивацию, а про дисциплину. Есть еще один важный лайфхак — на выходных дать себе выспаться. Чтобы пружина привыкла к натянутому состоянию, нужно много времени, поэтому нужно давать себе передышку.

5АМ | #мотивация

Какая база помогает тащить роль системного аналитика в проектах Локео (о проекте)

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

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

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

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

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

5АМ | #мотивация

Вот такой состав базы я выделил:

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

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

📌Знание устройства БД
Продумывая как данные бизнеса обернуть в систему, в голове уже строится образ ER-диаграммы c данными по сущностям и видами связей (один к одному, многие ко многим и т.д.).

📌Знание компьютерных сетей и запросов
Понимание работы протокола http, его запросов с конкретным методом, портов, получения фронтом нужных данных из БД по методам API, дает еще один образ движения данных в рамках системы.

📌Знание интерфейсов
Необходимо хотя бы базовое понимание устройства и работы компонентов, типовых элементов UI kit и подготовки прототипов, макетов в Figma, а также типов страниц, стандартных UX сценариев использования элементов и страниц. Системный аналитик в одном из слоев думает о приложении с позиции интерфейсов, поэтому необходимо иметь образы процессов разработки UX/UI.

📌Написание текстов
Все таки основная рутинная задача - это написание текста. Важно уметь и хотеть его писать, чтобы другие могли понять требования к системе. Текст в Docs - это IDE системного аналитика.

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

5АМ | #мотивация

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

А пока те самые три библейских вопроса любой разработки😝

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

5АМ | #мемы

Пятничная честность ❤️

Я поставил цель дорастить наш канал до 1000 крутых ребят до конца года. Сейчас мы приближаемся к 500(!!!) и возникла потребность четче сформулировать кто мы, кто я, зачем это все. Я веду канал уже полгода параллельно управлению компанией и разработке. За полгода не пропустил ни дня, сделав около 130 постов, по 5 дней, предоставляя вам контент с душой, лично пропущенный через меня, через мой опыт.

За полгода мне удалось плотно влиться в информационный поток телеграм каналов IT тематики. И понял, что есть три ниши для этого канала - это тусовка студий, стартаперская тусовка и продактовская тусовка. Этот канал где-то посередине.

Канал для продактов? И да и нет
У меня уже накопилось 7 лет коммерческого опыта продуктового управления, 6 из них в IT. Но управление продуктом, проектами, бизнес и системным анализом я занимался параллельно развитию бизнеса, т.е. объединяя с административными процессами.

Продактовская тусовка в основном из корпораций: Сбер, Яндекс, Ozon и т.д. (привет, ребят, если кто читает киньте 👋, вы крутые)) Ваши функции не так сильно смешаны, у корпораций есть деньги нанимать большой штат специалистов на каждый подпроцесс проектирования и развития.

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

Канал для стартаперов. И да и нет
Тут меня бомбанет)) Я читаю стартаперов. Весь нарратив постов как будто списан с сериала «Кремниевая долина». Экзиты-хуекзиты, питч-деки, фин. модели, единороги и прочие лошади. Я на опыте ощутил и понимаю, что устойчивую компанию построить очень сложно, собрать крутую команду еще сложне, эффективно разрабатывать ПО невероятно сложно, построить маркетинг и систему продаж - пфффф. Или мне одному так тяжело?))) (ну вот начал жаловаться)

Но самое важное - капитал не дают просто так. Ни фонд, ни государство, просто так: за бизнес план, красивую картинку в презентации, даже когда у тебя за плечами уже что-то есть, не дают. Никто за тебя процессы не построит, а инвестировать в компанию с плохими процессами - это сливать деньги на ветер. Инвестируют в бизнес. Как сделать бизнес? Не по-книжному, а вот реально, когда минимальная команда стоит 1.5 млн. руб. со всеми оптимизациями. Инвестор - не хочет терять деньги, поэтому процесс DD (проверки компании) растягивается (а платить нужно), а после ты подписываешь неприятные условия. Я честно признаю, что это тяжело и не прячусь за умными словами) Реальный бизнес суров, он не сказочный.

Я уволился из фсб, Серега из первого бита. Мы начали с разработки VR/AR для целей маркетинга как студия, параллельно развивая процессы веб и мобильной enterprise разработки с нуля. Мы простые ребята из народа, «от земли», делаем ошибки (например) и честно, без прекрас и красивых терминов, строим бизнес как студию и как IT продукт, потому что рассчитывам на себя. 6 лет в разработке как команда, 70 млн. привлекли инвестиций, сделали 5 крупных проектов, не считая Локео, который состоит еще из 8, 15-20 млн ежегодный оборот. Мы экспертны в разработке SAAS решений для b2b от проектирования с нуля до релиза, в VR/AR, в интернет-маркетинге. В нас есть огонь, желание и зрелость)

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

Если у вас есть идеи, вы хотите что-то обсудить, даже просто поболтать за решение, или вы думали за разработку, и нет тз, то я готов поделиться опытом и уделить время. 🫶 Пишите - @limskov.

5АМ | #мысли

Сколько у нас точек зрения?

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

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

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

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

— Имея образ иракской паукохвостой гадюки и понимание зачем ей такое строение хвоста, можно не удивляться зачем бизнес и люди столько тратят на системы безопасности.
— знание о том, как размещается один электрон в атоме в разный момент времени дает представление о том, что происходит с одной задачей с разных углов зрения: как проект, как запрос заказчика, как эпик и т.д
— представляя строение восточно-европейской равнины и карпатских гор можно понять причины поступков правителей Российской империи, СССР и РФ, сделав простой логический вывод.
— представляя работу диода и одиночный p-n переход, можно усложнить понимание и узнать о транзисторе, который как выключатель переключается и пропускает ток, а 8 транзисторов поставленные в положение 0000 0011, дают цифру 3, дальше ассемблер, с++, с# и вот уже у нас видос на ютубе работает))

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

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

P.S. завтра поговорим про CJM😝

5АМ | #философия

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

В общем я поделился в кружочке как можно такими эмоциональными взрывами управлять, а зачастую именно они рушат очень крутые отношения) Виктор, у нас все получится, все проблемы херня ❤️😘

Глубинные интервью

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

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

Закинул продуктовую гипотезу: "Если создать приложение для сотрудника HR отдела и приложение для кандидата, в котором будет процесс подготовки, загрузки и подписания документа с помощью усиленной неквалифицированной подписи с интеграцией с 1С, то это будет легитимно и не потребуется печатать доки и отправлять их СДЭК-ом. Это сэкономит ему деньги, поэтому он захочет купить наш продукт". Подготовил высокоуровневые требования к ней и описания.

Далее начинается интересное. Нужно выявить существующий процесс и существующие среды. BA/SA вступают в бой, ну или продакт в этой роли) Три этапа: подготовка, интервью, оформление.

Подготовка
Как сказал мой дед: я твой дед "Победа любит подготовку". Нужно заранее изучить предметную область, понятийный аппарат, имеющиеся среды обработки данных, участвующих лиц, подготовить список тупых вопросов. Например, узнать, что в цепочке участвуют: HR, кандидат, бухгалтер, курьер. Среды: 1С, excel, doc, может быть CRM hr-a.

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

Понимая весь процесс, идем к пользователю.

Интервью
По моему опыту нет лучше вопроса на интервью, который запускает выдачу данных, чем "Что вы, Тамара Григорьевна, делаете каждый день?" или "Что ты, серверная стойка с ПО, делаешь каждый день тут?". Остальное дело техники: задавать открытые вопросы, не перебивать, наводящими вопросами возвращать в нужное вам русло.

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

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

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

5АМ | #стартап

К вчерашнему посту был комментарий от Кнарик (мы с ней работали над Локео, оч. крутой дизайнер) закинула вопрос - почему исследования делает systems analyst , а не UX.

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

5АМ | #разработка

Кто в итоге должен проводить интервью: SA или UX или BA?

Вообще, все смешалось кони-люди)
Чтобы ответить, нужно понять вот что: кто в итоге - архитектор системы? UX или SA или вообще CTO? Разберемся, а зачем собственно и UX и SA интервью. Попытаемся расщепить обязанности:
— UX не должен анализировать данные, но без них он не сделает свою задачу, ведь проектировать интерфейс без данных пустая трата времени. UX не должен думать за внутрисистемные процессы, но тогда не выполнит свою работу качественно, потому что не поймет что делает программа.
— SA не сделает свою задачу без процесса в интерфейсах, ведь часть данных преобразуется в рамках процесса в интерфейсе, который определяет точки входа в операцию. На выходе косячно заложит требования.

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

Так кто в итоге архитектор? Если смастерить круги Эйлера: BA, SA и UX, то архитектор системы будет серединой. Главная проблема: если в одной голове это все еще можно подружить, то при расщеплении на роли "архитектором" является некая эмерджентность у команды как системы. Команда - это архитектор. Это не что иное как мельница Лейбница.

Поэтому, чтобы это уникальное свойство работало, возникает куча созвонов, перепалок, штурмов. Так и выходит, что на одном проекте UX перетянул на себя больше обязанностей, на другом больше SA. А потом на hr рынок вылетают профессии «продуктовый дизайнер», потому что какой-то бизнес просто плюнул и говорит, пусть это все будет называться так.

Из-за масштаба процесса проектирования в компании неизбежно возникает его деление на подпроцессы. Чтобы он работал эффективно, нужна такая тонкая настройка команды, что я в эффективность этого почти не верю. Получается, что бизнесу нужна команда креативщиков в носках с бананами минимум из 5-ти человек: продакт, UX, BA, SA, CTO) Вот и в месяц полтора миллиона бюджета нет) Боль😭

Как вывод, каждый может делать интервью, каждый должен делать интервью. Но считаю, что SA его должен делать первый, так как он может сформулировать процесс системы, который будет компилироваться по данным и без интерфейса. Он сделает предположение, что система вообще может работать так, а не система удобно может работать так. UX же уже идет к пользователю не с абстрактным вопросом «а как вам удобно», а вот смотрите есть вот такая проблема: мы можем их показать вот так, вот так и вот так. SA работает, когда нет интерфейса и БД. Это его стихия, потому что он делает свою работу на табличке с переменными, не спотыкаясь об проблемы интерфейса.

Остается вопрос: как команду превратить в "архитектора"? Вот это уже искусство)

Что думаете? 🎩

5АМ | #разработка

Завтра мемесы, хорош с лонгридами😝

Сегодня ездили фоткаться для сайта) Серега модный-мощный, испепелял фотографа взглядом😄😄

Про лицензионные соглашения

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

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

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

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

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

Чуть позже расскажу про политику конфиденциальности и пользовательские соглашения. Тоже важный момент в развитии продукта)

5АМ | #компания

Та самая грань между тройкой и двойкой

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

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

Он будет делать ровно столько, чтобы нельзя было придраться и сказать что совсем не работает или работает плохо. То есть это не оценка 2, а где-то 3 с минусом.

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

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

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

Важно не тянуть. Людей изменить нельзя. Вам просто не по пути.

5АМ | #команда

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

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

Уже как месяц читаю канал Екатерины Гулиной, CEO в Double Kate Consulting и руководитель партнерской сети в ЛАНИТ. В прошлом отстраивала процессы в Adidas и руководила HR департаментом в ИТ и телекоме. Короче заряженная💪

Катя ведет канал — @The_Gulina. Нравится как пишет, схожий tone of voice, делится опытом по-настоящему. Очень подробно дает методики анализа бизнес-процессов, их реставрации и внедрения. Пишет крутыми метафорами, люблю такое)

У меня была рубрика — цитатник. Суть переданная в короткую мысль работает как пуля-понимания. Мне кажется ключевые мысли — это лицо канала. Ниже собрал вам пачку инсайтов с канала, которые меня зацепили🔽🔽

5АМ | #рекомендации

✏️ Понимание людей. На старте карьеры я собеседовала от линейных сотрудников (массовые собеседования, когда целый зал кандидатов приходит) до ТОП-ов с зарплатами, как моя годовая на то время, за год 2-3 тыс человек. А еще сокращала отделы и проводила переговоры, повышала и понижала в должностях, ставила цели и развивала до руководителей. И сейчас, когда я разговариваю с человеком мне не важна его должность, как складно ссыт в уши, эмоции и др., я вслушиваюсь в смысл и ищу пользу, которую он может дать, чем я могу помочь. Если чирикают сверчки, то дай Бог ему здоровья и «слееедующий!» - нашел тут

✏️ Будучи сама топ-менеджером я всегда придерживалась и прививала сотрудникам один принцип "Обосраться, но не сдаться", потому что нет нерешаемых задач, просто на некоторые требуется больше времени, как вариант - для выстраивания или корректировки текущих процессов. - нашел тут

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

✏️ Как говорится «Лицом к лицу - лица не увидать», поэтому для управления бизнесом, крупными бизнес-процессами и проектами важно уметь посмотреть на них с высоты (применить helicopter view). Лайфхак, который помогает переключить свой внутренний зум с деталей на общий план (helicopter view) - это вид на панораму города с высокого этажа, колеса обозрения или самолета, главное оттуда, где мозг перестроится с ближнего плана на дальний. - нашел тут

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

✏️ Создание процесса стоит только вашего времени или времени консультанта, который его выстраивает, а вот его отсутствие риск потратиться на активы / ресурсы, которые могут не работать и тянуть в минус, или приносить недостаточную прибыль. - нашел тут

✏️ Философия рассказывает о взгляде на процессы жизни и объясняет откуда взялся такой вывод. Вы можете соглашаться с автором или нет, но альтернативное мнение взгляда на мир уже появилось в вашей голове. Более того вы можете усомниться в верности своих убеждений, которые не поддавались ранее критике. - нашел тут

✏️ Ответственность – цена успеха. Быть ответственным не равно быть виноватым. Быть ответственным - это признать ошибку и исправить ее, вместо того, чтобы искать виноватого. - нашел тут

5АМ | #рекомендации

Написано кровью деньгами — не блокируй процесс

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

5АМ | #управление

Возьму только один пример.

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

Я привязал один процесс, оценку, к другому процессу - проектированию ПО в новой версии. Почему? Хорошо проработанные и упакованные по версиям требования позволяют дать очень точную оценку с корректировкой не более чем в 10-15%. Руководитель направления может произвести оценку, дать обратную связь и сделать декомпозицию, которую можно далее пустить в процесс оценки: расчет стоимости от цены часа и т.д.

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

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

Расщепить - Распараллелить

🟣 Расщепить
Считаю, что это фундаментальнейший навык высококласных спецов. Чем выше скорость расщепления после того, как в голову поступила инфа, тем выше уровень спеца.

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

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

Например, обновление high-level ux платформы не должен блокировать поставку макетов в разработку. Два разных результата. Можно было бы поставить их в ряд и сказать "пока мы не обновим ux - дальше не двигаемся". Разработка - денег стоит, нельзя её блочить.

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

🟣 Распараллелить
Когда произведено расщепление, то разводим работу, обозначая два разных результата и думаем в будущем о мерже.

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

Попадались в сцепку процессов?

5АМ | #управление