Телеграм канал «Наташа Косинова. Варю айти СУП»

📊 Папка по бизнес - аналитике — инструмент для тех, кто хочет управлять данными и решениями, а не хаосом ADOBE ВЫПУСТИЛА 10 ИИ-АГЕНТОВ, А У ТЕБЯ — 10 ПОВОДОВ ПЕРЕПИСЫВАТЬ ОТЧЁТ Здесь вы найдете: - Чек-лист ежедневных действий Руководителя проекта / Продакта или любого руководителя! - Пошаговые чек-листы для анализа рынка, конкурентов и бизнес-процессов - Практические методики для построения CJM, финансовых моделей и unit-экономики - Готовые шаблоны отчетов и презентаций для инвесторов и руководства - Разборы кейсов: от стартапов до крупных компаний Все материалы собраны в удобном формате, без лишней теории — только практика, применимая прямо сегодня. ЗАБРАТЬ ПАПКУ

📊 Папка по бизнес - аналитике — инструмент для тех, кто хочет управлять данными и решениями, а не хаосом ADOBE ВЫПУСТИЛА 10 ИИ-АГЕНТОВ, А У ТЕБЯ — 10 ПОВОДОВ ПЕРЕПИСЫВАТЬ ОТЧЁТ Здесь вы найдете: - Чек-лист ежедневных действий Руководителя проекта / Продакта или любого руководителя! - Пошаговые чек-листы для анализа рынка, конкурентов и бизнес-процессов - Практические методики для построения CJM, финансовых моделей и unit-экономики - Готовые шаблоны отчетов и презентаций для инвесторов и руководства - Разборы кейсов: от стартапов до крупных компаний Все материалы собраны в удобном формате, без лишней теории — только практика, применимая прямо сегодня. ЗАБРАТЬ ПАПКУ

"Я сам решу" - резюмирую наше с вами вчерашнее обсуждение. Много интересных мыслей, советов, историй из жизни, схем общения. Как не крути, ответ разработчика "я сам решу", больше похож на начало конфликта, может даже скрытого. Тут и принебрежение есть, и страх, и повышенное чсв. И много ещё чего скрыто, и конечно контекст может быть любой, как и среда работы нашего аналитика. Я приводила в пример, историю из своей жизни, когда на моё тз разработчик кричал "какой мудак это написал!" За чувства другого мы не отвечаем))) И тут я даже больше рада, что они есть. И вцелом наш кричащий разработчик, потом адекватно всё обсуждал. Мы можем рассказать о своих чувствах, есть схемы. Но имхо, тут нужно понимать, с кем ты общаешься и стоит ли такое задвигать. Есть схема по формуле: Когда ты делаешь вот так, я чувствую вот это, предлагаю договориться и делать вот так. Например, когда ты говоришь, что сам решишь, я чувствую, что не выполняю свою работу, давай договоримся в каком виде хотелось бы получать подобные требования в тз, и может есть пример? Примеры, всегда хорошо. Часто их нет у разработчиков, но они есть у аналитиков))) ✅Вообщем, резюме такое, что как не крути, нужно выстраивать коммуникацию, общаться, договариваться и определять границы ответственности. ✅В этом нам помогут общие правила. Эти правила, можно фиксировать отдельно, как внутренние регламенты взаимодействия. ✅Мы с командой часто договаривались о том, как будем описывать атрибуты сущности, какой берём формат, и какие типы за основу. Даже можно просто на русском названия описать. Типы атрибутов зависят от того, как мы будем обрабатывать данные, какие будут преобразования, вычисления, где, как, что будет храниться в том числе. Часто достаточно перечислить необходимые требования. ✅Конечно тут поможет эскалация, если есть куда эскалировать. Часто мне помогали тим лиды разработки, айти директора, кто-то над разработчиками. Если тебя не слушают, и игнорируют, а такое со мной случалось, то слово директора, помогает. ✅Есть ещё момент, если команда никогда не работала с аналитиком, то может быть состояние "Аналитик нам мешает, без него было лучше". Что тут скажешь, приходится продавать себя как личность, и должность, и показывать результат. У меня как-то разработчик от резкого отрицания "я всегда работал без аналитика", через год пришёл к тому, что "что без аналитика не начинаю разработку". ✅Опыт за плечами у каждого разный. Кто-то больше, кто-то меньше видел разное дерьмо. И раны нанесенные разные, кто-то не видел хороших аналитиков, а кто-то не видел хороших разработчиков, но мы уже вместе на этой подводной лодке и надо делать общее дело. ✅Конечно в общее дело все вкладываются, но иногда отношение к коду может быть как к детищу, и отсюда резкие не лезь. ✅Лучший друг и товарищ аналитика, тестировщик, он может сказать, что код не по ТЗ и какие-то требования не выполнены. Как мы видим вариантом много. И тут нужны те самые soft skills, при этом принято считать, что технарям, инженерам они не нужны. Дали мне тз и пошёл, я по нему работать. А вот не всё так просто... )) #итого #историяизжизни #моемнение #самрешу

Разработчик говорит - "Я сам решу!" Итак, реальная ситуация. Аналитик описывает в требованиях типы атрибутов для полей, которые выводятся на экране, а потом обрабатываются системой и лягут в таблицы БД. Разработчик хмурится и говорит: "Не лезь на мою территорию! Я сам решу!" По схеме БД, которую сделал аналитик, разработчик говорит тоже самое. Ваши рекомендации, действия? 😎 #кейс #историяизжизни

🍃Сентябрь мне сказал - я сам решу! И перепутал мне планы, но я позлилась не унываю! ---------------------------- ✍️Итак, внезапно для менти, я решила резко, дерзко провести тренинг по сбору требований "Китайская ручка". 🚀Стартуем уже завтра вечером! Даты и время тренинга: 👉18 сентября с 19:00 до 21:30, с перерывом 10 мин 👉19 сентября с 19:00 до 21:30, с перерывом 10 мин 👉21 сентября с 10:00 до 13:00, с перерывом 10 мин. Время по Москве Почитать подробнее и оставить заявку можно на лэндинге. ---------------------------- Также сложно с запуском пилота тренинга по бизнес-анализу Большая стирка, но я не унываю))) Поэтому выкалачиваю даты в граните! Цена, очень привлекательная, так как это пилот! 6 октября (пон) 9 октября (ср) 10 октября (пят) с 19:00 до 21:30 по Москве Почитать подробнее и оставить заявку можно на лэндинге. ---------------------------- 📈И для тех кто хочет посложнее, и погорячее, вызов в виде проектирования, тут у нас Курс Интеграции (марафон на 2 месяца). Не всем он по силу💪, но те кто проходит растёт в должности, и зарплате. Дату старта перенесли на гранит - 9 октября! Почитать подробнее и оставить заявку можно на лэндинге.

В ТЗ напишите всё! Продолжение поста выше. Благодарю за интересное обсуждение темы "Всё написать в ТЗ"! Обожаю своих подписчиков, всегда много крутых идей, шуток и комментариев! 😎👏 Конечно, аналитику можно душнить по поводу того, что такое "всё"? И справедливо было замечено, что такими абстрактыми понятиями оперируют менеджеры, особенно когда нужно, что-то продать заказчику. Мы всё опишем в ТЗ! Кто эти мы, и что такое всё.... Ещё очень интересную информацию узнала, что по исследованиям человек, который много говорит на абстрактном языке кажется умнее, того, кто говорит четкими понятиями. Вот отсюда ноги растут доверия политикам и продажникам) Что хочется сказать: ✅1.Во впервых, нет идеальных ТЗ, мы только можем стараться сделать их идеальными. И я бы слово идеальное заменила на "достаточно хорошим", хотя тоже, что такое "хорошо"? Или что такое понятно? Кому понятно? Тут каждый сам определяет. Я одно время говорила, что понятно, это когда количество вопросов и комментариев уменьшается от раза к разу) Но тоже если нет вопросов к ТЗ, значит его никто не читал. #мудрость ✅2.Во вторых, аналитик работает в условиях высокой неопределённости. И отсюда у нас и появляются разные способы, уменьшения этой неопределённости. Это и попытка НЕ уходить в детали (пример, агил, срам и user story, пользовательским уровнем требований можно управлять), это и шаблоны ТЗ, стандарты, и справедливо было замечено, что это культура "у нас так непринято". И политический аспект, нужно что-то оставить для маневра. И автогенерация ТЗ из того, что уже сделано или, что мы можем точно реализовать (у нас так было на одном проекте, очень удобно, это как шаблонный договор с заказчиком). ✅3.В третьих, нужно смотреть на стадию проекта. На самом старте высокая неопределённость, но на этапе уже такого хорошего развития, неопределённость может быть и 30%. И тут уже будет проще, но сложнее с внедрением в то, что уже работает. В начале проекта у нас высокая степень неопределённости и описать вообще всё - это утопия. Мы сможем описать всё, когда проект будет завершён и будет написан код. Код и является самым подробным, детальным уровнем ТЗ. Обычно, нет времени, и конкуренция на рынке не ждёт, мы не можем писать ТЗ до тех пор, когда всё будет понятно. Хватает основы, концепта. Когда уже понятно, как двигаться дальше,какая архитектура будет, какие технологии нам нужны мы уже понимаем как сделать первый шаг, мы его и делаем. И конечно, хотелось бы ещё сказать, что понятны риски, иначе как всё стартовать. И вот делаем шаги, а получаем сразу возврат, что не так, и корректируем. И так входим в цикл за циклом. Живой бизнес, это организм, он меняется, и всё быстро устаревает, поэтому часто надо уже дать пользователю хоть что-то. Я не видела не одного проекта, где бы мне дали достаточно времени, чтобы уйти в детали и их описать в ТЗ. Мы не пишем годами такие документы, не та сфера, нет в этом смысла. Проект без изменений это утопия, либо он никому не нужен, а ТЗ, это способ уменьшить количество изменений и приблизить вижен к реальности, поэтому тут и появляется искусство написания формулировок, опыт, насмотренность аналитика. И лавирование в конкретной среде. #описатьвсё #тз #мысливслух #рассуждения