Нужен ли стартапу офис?)
Всем доброго вечера, я вот задумался на днях об этом вопросе, когда планировал статью расхода: аренда помещений) За все время работы мы успели поработать и в коворкинге, и в полноценном офисе, и даже у меня дома))
Вот в начале 2020 г. у нас крутой (относительно конечно) офис на Тульской с видом на купола, а уже в феврале злосчастный чудо эксперимент - ковид) Мы сворачиваемся и разъезжаемся по домам... И с этого момента начинается удалёнка. Так получилось, что юридически наша компания создалась без офиса, то есть мы с рождения виртуальная компания)) Конечно у нас есть юридический адрес, где мы появляемся, храним учредительные и всякие юр штуки, но все таки вайб не тот...
Понятно, что во всем есть свои плюсы и минусы. Вот я и задумал описать их:
Плюсы:
- ну наверное самый очевидный - это деньги. Конечно не нужно скидывать на аренду, печенки, чаёк и принтеры и все такое.
- не нужно ехать, можно хоть с кровати не вставать, проснулся - открыл ноут и поехали)
- иии да... и все, блин))
Минусы:
- жирный, прям такой что отдышка. Нет ощущения компании. Я порой сажусь за стол дома и ощущение, что безработный😄
- потом, вот еще один: нельзя решить проблему очень фастово так, что просто поднимаешь голову через экран и криком "Жень, ёпт, чет кнопка мозги делает". Нет, надо писать, объяснять, созвониться и все такое. То есть коммуникации, как бы не казалось, что связь есть и моментальная, не работают в полной мере.
- еще один минус, прям жирный Билли: порой нет ощущения команды, то есть нужны прям потуги) То есть, ну камон, нас 10 человек, офис на 10 человек - это прям весело (да нужно работать с серьезными минами какое-то время, но просто посмеяться тоже нужно), это драйвово, это,ну..., заряжает блин) Да просто крикнуть: "Мы промучались 10 часов, но таки мы починили этот чертов баг, детка! Идем в Mollie's с меня пиво") В этом прям важный момент: люди сближаются от совместных моментов вместе, от сложностей, преодоления или просто крутой вовремя сказанной шутки. Эххх. Один момент с Серегой чего стоит, когда мы кранчили 36 часов подряд, я бредил, а он в обморок упал потом)) Да эт ужасно, но блин, эт весело)
Короче наболело. Хочется офиса, на месяцок... а потом задолбает ездить на метро и по пробкам и снова удаленки захочется, ахах))
Что думаете? Офис нужен или черт с ним?)
Пойду дописывать доки к гранту. Лайфхак: Как написать 40 страниц за 2 дня? Metallica и AC/DC, входим в транс и пошло поехало💪💪💪 Всем заряда и спокойной ночи! Обнял через экран))
5АМ | #стартап
Всем доброго вечера, я вот задумался на днях об этом вопросе, когда планировал статью расхода: аренда помещений) За все время работы мы успели поработать и в коворкинге, и в полноценном офисе, и даже у меня дома))
Вот в начале 2020 г. у нас крутой (относительно конечно) офис на Тульской с видом на купола, а уже в феврале злосчастный чудо эксперимент - ковид) Мы сворачиваемся и разъезжаемся по домам... И с этого момента начинается удалёнка. Так получилось, что юридически наша компания создалась без офиса, то есть мы с рождения виртуальная компания)) Конечно у нас есть юридический адрес, где мы появляемся, храним учредительные и всякие юр штуки, но все таки вайб не тот...
Понятно, что во всем есть свои плюсы и минусы. Вот я и задумал описать их:
Плюсы:
- ну наверное самый очевидный - это деньги. Конечно не нужно скидывать на аренду, печенки, чаёк и принтеры и все такое.
- не нужно ехать, можно хоть с кровати не вставать, проснулся - открыл ноут и поехали)
- иии да... и все, блин))
Минусы:
- жирный, прям такой что отдышка. Нет ощущения компании. Я порой сажусь за стол дома и ощущение, что безработный😄
- потом, вот еще один: нельзя решить проблему очень фастово так, что просто поднимаешь голову через экран и криком "Жень, ёпт, чет кнопка мозги делает". Нет, надо писать, объяснять, созвониться и все такое. То есть коммуникации, как бы не казалось, что связь есть и моментальная, не работают в полной мере.
- еще один минус, прям жирный Билли: порой нет ощущения команды, то есть нужны прям потуги) То есть, ну камон, нас 10 человек, офис на 10 человек - это прям весело (да нужно работать с серьезными минами какое-то время, но просто посмеяться тоже нужно), это драйвово, это,ну..., заряжает блин) Да просто крикнуть: "Мы промучались 10 часов, но таки мы починили этот чертов баг, детка! Идем в Mollie's с меня пиво") В этом прям важный момент: люди сближаются от совместных моментов вместе, от сложностей, преодоления или просто крутой вовремя сказанной шутки. Эххх. Один момент с Серегой чего стоит, когда мы кранчили 36 часов подряд, я бредил, а он в обморок упал потом)) Да эт ужасно, но блин, эт весело)
Короче наболело. Хочется офиса, на месяцок... а потом задолбает ездить на метро и по пробкам и снова удаленки захочется, ахах))
Что думаете? Офис нужен или черт с ним?)
Пойду дописывать доки к гранту. Лайфхак: Как написать 40 страниц за 2 дня? Metallica и AC/DC, входим в транс и пошло поехало💪💪💪 Всем заряда и спокойной ночи! Обнял через экран))
5АМ | #стартап
Всех с пятницей🤘! Давай расскажу о принципах и методах управления в стартапе.
Для каждого уровня развития компании требуются своим методы управления. Метод хаоса, подростка и зрелого дяди (личные названия и градации, наверняка в MBA есть какие-нибудь FACK модели, но это скучно). Первый, для начала жизни компании, второй, расширения и развития, третий, для устойчивости. Разберем первый)
Чтобы понять как управлять, нужно понять как привлекать людей в команду)
Для понимания подойдет метафора привлечения сексуального партнера (чуть сексизма)😆 Вот если есть у тебя красивые ноги, глаза, «глаза», широкая спина (тут для мужчин, ахах), то и привлечение партнера идет проще, а если нет - то будь добр крутись - кабанчиком, показывай чувство юмора, находчивость и все такое)
Так вот, ты понял, что есть крутой продукт, есть бюджет, но компанию только создали, дай бог есть логотип, Петя, Вася и кот Олег)
Что есть у компаний подростков (вышедших из пубертата) и зрелых дядей: да, ЗП, но еще спорт зал, зубной, персональный массажист всех участков тела, отпуск (в который, когда уходят, у тебя не возникает нервного тика), макбук на входе, наставник, и в попу поцелуй) Это все как раз и есть ноги, глаза и «глаза»))
Что есть у малышей (хаоса): куча интересных задач, зачатки систем, которые параллельно нужно строить, которые не забирает синьор, ламповость команды, адекватность людей, с которыми работаешь, драйв и определенная свобода, а ну и ЗП по средней отметке рынка и прямая работа с тем, кто эту кашу заварил.
Лично я выделил следущие важные элементы, которые позволяют команде не расклеиваться (кстати все ребята тут, так что могут меня закидать 💩)
- Адекватность, адекватность и еще раз адекватность. Со стороны члена команды: Адекватно воспринимать нагрузку, адекватно воспринимать работу других ребят, адекватно относится к шероховатостям и сложностям. Со стороны управления: адекватно воспринимать навыки, адекватно воспринимать результаты работ. Слишком много этого слова, я как нибудь напишу про этот принцип. Считаю, что он прям мега важен)
- Уделять внимание. Из-за того, что команда небольшая, можно поговорить по-душам. Именно за этим иногда и приходят в небольшую компанию. В ней ты не теряешься, в ней ты - не винтик. Я часто общаюсь со всеми, мне нравится это делать, и именно потому что в этом нет фальши, из-за того, что идет от души - в это веришь и ты сам и человек.
- Давать возможность роста или забота. Дать прям сложные задачи и самому человеку в них разбираться и вариться. Это важная точка для будущего развития карьеры человека, даже если вы разойдетесь, но потом он сможет сказать: «вот видите, это сделал я от и до, знаю все тонкости и нюансы».
Могу дать больше, но уже лонгрид, мне тут подсказывают, что их не любят) Оставляйте коменты и реакции, я так буду понимать, что заходит, а что в урну))😜
5АМ | #стартап
Для каждого уровня развития компании требуются своим методы управления. Метод хаоса, подростка и зрелого дяди (личные названия и градации, наверняка в MBA есть какие-нибудь FACK модели, но это скучно). Первый, для начала жизни компании, второй, расширения и развития, третий, для устойчивости. Разберем первый)
Чтобы понять как управлять, нужно понять как привлекать людей в команду)
Для понимания подойдет метафора привлечения сексуального партнера (чуть сексизма)😆 Вот если есть у тебя красивые ноги, глаза, «глаза», широкая спина (тут для мужчин, ахах), то и привлечение партнера идет проще, а если нет - то будь добр крутись - кабанчиком, показывай чувство юмора, находчивость и все такое)
Так вот, ты понял, что есть крутой продукт, есть бюджет, но компанию только создали, дай бог есть логотип, Петя, Вася и кот Олег)
Что есть у компаний подростков (вышедших из пубертата) и зрелых дядей: да, ЗП, но еще спорт зал, зубной, персональный массажист всех участков тела, отпуск (в который, когда уходят, у тебя не возникает нервного тика), макбук на входе, наставник, и в попу поцелуй) Это все как раз и есть ноги, глаза и «глаза»))
Что есть у малышей (хаоса): куча интересных задач, зачатки систем, которые параллельно нужно строить, которые не забирает синьор, ламповость команды, адекватность людей, с которыми работаешь, драйв и определенная свобода, а ну и ЗП по средней отметке рынка и прямая работа с тем, кто эту кашу заварил.
Лично я выделил следущие важные элементы, которые позволяют команде не расклеиваться (кстати все ребята тут, так что могут меня закидать 💩)
- Адекватность, адекватность и еще раз адекватность. Со стороны члена команды: Адекватно воспринимать нагрузку, адекватно воспринимать работу других ребят, адекватно относится к шероховатостям и сложностям. Со стороны управления: адекватно воспринимать навыки, адекватно воспринимать результаты работ. Слишком много этого слова, я как нибудь напишу про этот принцип. Считаю, что он прям мега важен)
- Уделять внимание. Из-за того, что команда небольшая, можно поговорить по-душам. Именно за этим иногда и приходят в небольшую компанию. В ней ты не теряешься, в ней ты - не винтик. Я часто общаюсь со всеми, мне нравится это делать, и именно потому что в этом нет фальши, из-за того, что идет от души - в это веришь и ты сам и человек.
- Давать возможность роста или забота. Дать прям сложные задачи и самому человеку в них разбираться и вариться. Это важная точка для будущего развития карьеры человека, даже если вы разойдетесь, но потом он сможет сказать: «вот видите, это сделал я от и до, знаю все тонкости и нюансы».
Могу дать больше, но уже лонгрид, мне тут подсказывают, что их не любят) Оставляйте коменты и реакции, я так буду понимать, что заходит, а что в урну))😜
5АМ | #стартап
Рубрика - ошибки
🧐При совершенствовании процессов аналитики мы вывели важную мысль - "не спотыкайся о среды". Notion, Битрикс, Excel, Trello, рюкзак с бумагами - это все среды хранения информации процесса.
Вот мы хотим добавлять данные контрагентов, а вот в notion, в crm-ке или в excel. "В notion удобнее, там же таблицы связывать можно, объединим их с оплатами" - с придыханием сказал, менеджер Аркадий, закатил глаза)) И мысль абсолютно уводит в другое. Споришь до хрипоты и розовых слюней. Придумываешь ошибки, сложности расширения, где интерфейс удобнее, а вот "возможности уведомления на эплвоч нееееет" и вообще гори оно огнем, я увольняюсь.
Сначала процесс, сначала данные, их характер и объем, потом выбор подходящей среды или совокупность сред.
Вот если у тебя один проект нужна тебе сложная система планирования и приоритезации. Нет, блин. Таблички, сначала таблички, а потом уже когда заработало и внедрилось, потом уже Jira, Notion и другие инструменты для дядей. Нужна тебе crm, если у тебя объем продаж 4 штуки в месяц и 52 в год. Нет, блин. Не достоин еще) Таблички, сначала таблички... Потом сложные CRM, автоматизации.
Не усложняй, Аркадий, не усложняй, дружочек😕
5АМ | #стартап
🧐При совершенствовании процессов аналитики мы вывели важную мысль - "не спотыкайся о среды". Notion, Битрикс, Excel, Trello, рюкзак с бумагами - это все среды хранения информации процесса.
Вот мы хотим добавлять данные контрагентов, а вот в notion, в crm-ке или в excel. "В notion удобнее, там же таблицы связывать можно, объединим их с оплатами" - с придыханием сказал, менеджер Аркадий, закатил глаза)) И мысль абсолютно уводит в другое. Споришь до хрипоты и розовых слюней. Придумываешь ошибки, сложности расширения, где интерфейс удобнее, а вот "возможности уведомления на эплвоч нееееет" и вообще гори оно огнем, я увольняюсь.
Сначала процесс, сначала данные, их характер и объем, потом выбор подходящей среды или совокупность сред.
Вот если у тебя один проект нужна тебе сложная система планирования и приоритезации. Нет, блин. Таблички, сначала таблички, а потом уже когда заработало и внедрилось, потом уже Jira, Notion и другие инструменты для дядей. Нужна тебе crm, если у тебя объем продаж 4 штуки в месяц и 52 в год. Нет, блин. Не достоин еще) Таблички, сначала таблички... Потом сложные CRM, автоматизации.
Не усложняй, Аркадий, не усложняй, дружочек😕
5АМ | #стартап
Сказ о том как мы посреди разработки стэк меняли😭
В прошлом году прямо на середине продакшена Локео мы переобулись в воздухе по части стэка. Как это произошло? (Вообще - никому не советую).
Исторически так сложилось, что бэк MVP продукта создавался на php, что уже само по себе ошибка, но помимо прочего он создавался на чистом php (фатальная ошибка), без использования фреймворков. Не спрашивайте как так получилось, но это очень серьезный факап планирования проекта. Концепция платформы создавалась достаточно долго и первые прототипы, как я говорил раньше, были сделаны на базе CRM и CMS (систем). В Локео очень тяжелый бэк, с большим количеством связей и в какой-то момент разработка логики на php стала идти оч туго. Мы буквально сидели на достаточно простых разделах по нескольку месяцев, фронтент пилился очень долго, а сама логика оставляла желать лучшего (тормозило жуть).
Тут мы созваниваемся с Серегой (он проект не вел с самого начала, а подключился к управлению, когда уже пошла разработка), и он мне говорит: “Клим, у нас два пути: либо мы сменим стэк либо 100% - это будет не рабочий продукт, не говоря уже о сроках”. И он предложил тестово в течение 2-х недель пересобрать часть логики на C#. Серега пропадает на две недели и возвращается с 3-мя сделанными разделами. Пришло время показывать что получается фронтам. Счастья их не было предела: как легко все подключалось и быстро работало. Тут я понял, что встал перед серьезным выбором…
В то время я плотно занимался бизнес анализом (потому что Локео - это сплошной комок бизнес процессов), аналитикой продукта и проектированием макетов приложения с дизайнерами. Отчасти благодаря тому, что у нас было много наработано и найдено технических и ux решений, а также завершено проектирование платформы в целом, нам удалось так быстро перейти на новый стэк.
Но… у меня два сотрудника php бэкендера, которые просто выпадают из цепочки. Пришлось принимать тяжелое решение об увольнении двух очень крутых ребят: Леши и Вадима, а Сереге пришлось садиться на лютый кранч. Как мне рассказывали потом - все ребята в команде заволновалась.
Думаю, что это было самое не простое решение из тех, что я принимал за свой опыт, и не самые простые общения с ребятами и командой. Но именно оно позволило в итоге воплотить в жизнь, то что тестируется и релизится сейчас. Да с увеличением затрат денег, но не с полной их потерей. Этот пост, об ошибках и тяжелых решениях, а также дань уважения офигенной работе Леши и Вадима (Привет, Ребят!), которые справлялись с работой в таком тяжелом проекте.
А какие вы самые тяжелые решения принимали? Отпустите душу😁
5АМ | #стартап
В прошлом году прямо на середине продакшена Локео мы переобулись в воздухе по части стэка. Как это произошло? (Вообще - никому не советую).
Исторически так сложилось, что бэк MVP продукта создавался на php, что уже само по себе ошибка, но помимо прочего он создавался на чистом php (фатальная ошибка), без использования фреймворков. Не спрашивайте как так получилось, но это очень серьезный факап планирования проекта. Концепция платформы создавалась достаточно долго и первые прототипы, как я говорил раньше, были сделаны на базе CRM и CMS (систем). В Локео очень тяжелый бэк, с большим количеством связей и в какой-то момент разработка логики на php стала идти оч туго. Мы буквально сидели на достаточно простых разделах по нескольку месяцев, фронтент пилился очень долго, а сама логика оставляла желать лучшего (тормозило жуть).
Тут мы созваниваемся с Серегой (он проект не вел с самого начала, а подключился к управлению, когда уже пошла разработка), и он мне говорит: “Клим, у нас два пути: либо мы сменим стэк либо 100% - это будет не рабочий продукт, не говоря уже о сроках”. И он предложил тестово в течение 2-х недель пересобрать часть логики на C#. Серега пропадает на две недели и возвращается с 3-мя сделанными разделами. Пришло время показывать что получается фронтам. Счастья их не было предела: как легко все подключалось и быстро работало. Тут я понял, что встал перед серьезным выбором…
В то время я плотно занимался бизнес анализом (потому что Локео - это сплошной комок бизнес процессов), аналитикой продукта и проектированием макетов приложения с дизайнерами. Отчасти благодаря тому, что у нас было много наработано и найдено технических и ux решений, а также завершено проектирование платформы в целом, нам удалось так быстро перейти на новый стэк.
Но… у меня два сотрудника php бэкендера, которые просто выпадают из цепочки. Пришлось принимать тяжелое решение об увольнении двух очень крутых ребят: Леши и Вадима, а Сереге пришлось садиться на лютый кранч. Как мне рассказывали потом - все ребята в команде заволновалась.
Думаю, что это было самое не простое решение из тех, что я принимал за свой опыт, и не самые простые общения с ребятами и командой. Но именно оно позволило в итоге воплотить в жизнь, то что тестируется и релизится сейчас. Да с увеличением затрат денег, но не с полной их потерей. Этот пост, об ошибках и тяжелых решениях, а также дань уважения офигенной работе Леши и Вадима (Привет, Ребят!), которые справлялись с работой в таком тяжелом проекте.
А какие вы самые тяжелые решения принимали? Отпустите душу😁
5АМ | #стартап
Слона едят кусочками)
Чем отличается "разработать первую версию приложения таск менеджера" от "разработать модуль аналитики таск менеджера" или от "разработать ИИ генератор названий задач"? Ничем) Все это проекты, просто разного масштаба)) Ведь проект - это просто желание добиться нового состояния, сделав n действий.
Но можно легко усложнить и подумать, что приложение, ну это что-то большое, тогда это ПРОЕКТ, второе, ну это модуль, какой-то большой блок, ну а третье, это просто фича, свойство. И типа фича внутри блока, блок внутри проекта. И вот, ты уже усложнил, добавив минимум четыре уровня погружения) На первом несколько проектов, на втором все модули всех проектов, на третьем все фичи модулей, в фичах задачи фичи. Прогрессия геометрическая.
Нужно всегда стараться оставаться только на двух уровнях. Проект-задача. Но как?
Все кроется в идентификации... Как понять что есть что. Вопрос - "Могу ли я представить образ результат того, что мы хотим сделать?". Неточные образы, абстрактное "сделать информативные графики для задач" не подходит.
Результат = Проект. Например, таблица с расчетами фин. модели - это проект. Документ аналитики и пачка вайерфреймов для раздела управления задачей - это проект. Не проект - это модуль финансовой системы или внедрить систему отчетности. Отсутствие конкретики худшее для определения приоритетов. Пуште конкретику.🎁
Отсюда выходит и роадмапинг. Результат определяет вехи, а вехи уже можно бить в роадмаппинг. Такие проекты можно оценивать в деньги, можно оценивать в сроки. Точность определяется от результата к результату. Т.е. от проекта к проекту. А сумма таких проектов формирует глобальную оценку "ПРОЕКТА"☝️ - ответ на библейский вопрос "сколько нужно и когда сделаешь". Важно определять входы-выходы для каждого проекта. Об этом расскажу завтра.
Знаю банально) Банальщину нужно повторять))
5АМ | #стартап
Чем отличается "разработать первую версию приложения таск менеджера" от "разработать модуль аналитики таск менеджера" или от "разработать ИИ генератор названий задач"? Ничем) Все это проекты, просто разного масштаба)) Ведь проект - это просто желание добиться нового состояния, сделав n действий.
Но можно легко усложнить и подумать, что приложение, ну это что-то большое, тогда это ПРОЕКТ, второе, ну это модуль, какой-то большой блок, ну а третье, это просто фича, свойство. И типа фича внутри блока, блок внутри проекта. И вот, ты уже усложнил, добавив минимум четыре уровня погружения) На первом несколько проектов, на втором все модули всех проектов, на третьем все фичи модулей, в фичах задачи фичи. Прогрессия геометрическая.
Нужно всегда стараться оставаться только на двух уровнях. Проект-задача. Но как?
Все кроется в идентификации... Как понять что есть что. Вопрос - "Могу ли я представить образ результат того, что мы хотим сделать?". Неточные образы, абстрактное "сделать информативные графики для задач" не подходит.
Результат = Проект. Например, таблица с расчетами фин. модели - это проект. Документ аналитики и пачка вайерфреймов для раздела управления задачей - это проект. Не проект - это модуль финансовой системы или внедрить систему отчетности. Отсутствие конкретики худшее для определения приоритетов. Пуште конкретику.🎁
Отсюда выходит и роадмапинг. Результат определяет вехи, а вехи уже можно бить в роадмаппинг. Такие проекты можно оценивать в деньги, можно оценивать в сроки. Точность определяется от результата к результату. Т.е. от проекта к проекту. А сумма таких проектов формирует глобальную оценку "ПРОЕКТА"☝️ - ответ на библейский вопрос "сколько нужно и когда сделаешь". Важно определять входы-выходы для каждого проекта. Об этом расскажу завтра.
Знаю банально) Банальщину нужно повторять))
5АМ | #стартап
Как типология, конфликтология и сценаристика помогают в аналитике процессов?
Пост на серьезных щщах😐Этим постом открою цикл постов по философии сознания как подход к анализу цифровых продуктов. Будет глубоко, много, но интересно) Буду опираться на обратную связь, так как не знаю зайдет или нет. Пишите что не понятно и как раскрыть дальше или не раскрывать вообще)
5АМ | #стартап
Пост на серьезных щщах😐Этим постом открою цикл постов по философии сознания как подход к анализу цифровых продуктов. Будет глубоко, много, но интересно) Буду опираться на обратную связь, так как не знаю зайдет или нет. Пишите что не понятно и как раскрыть дальше или не раскрывать вообще)
5АМ | #стартап
Сценаристика
В долгосрочную перспективу меня очень интересует сценаристика в связке с геймдевом, поэтому я начал прокачиваться в написании сценария. В сценарии очень строгая структура. Сценарист рассказывает историю. История рассказывается через призму события. Событие - это всегда изменение состояния героя. Событие проявляется через конфликт: восстановить разрушенные отношения с отцом, получить работу мечты, добиться отношений с девушкой/парнем, которой недостоин/недостойна, спасти мир в конце концов. Все это укладывается в кадр, сцену, акт, эпизод. В последнем происходит кульминация изменения - решение конфликта.
Вся наша жизнь: вчерашний день, прошлый год - это тысячи историй. История не может быть без конфликта, иначе она не будет интересна. Меня заинтересовала тема конфликта как абстракция. Что такое конфликт? Если он лежит прям в корне, значит это можно хакнуть и использовать в работе и развитии продуктов, интерфейсов.
Конфликтология
Есть даже наука конфликтология. В корне любого конфликта любого уровня лежит борьба и всегда за ресурсы. Тут не обойтись без примеров. Старший брат видит как младшему брату достаётся больше внимания и начинает отвешивать лещей младшему. Недалекий начальник подставляет нового амбициозного подчиненного специалиста. Наш сервис Локео делает нишевые фичи для загородного рынка, чтобы конкурировать с Домилендом. США в 1920-х как развитое государство с кризисом перепроизводства на континенте, на котором уже некому продавать товары.
Что объединяет все эти конфликты? Что-то одно. Если это что-то объединяет историю, которая и есть наша с вами жизнь, то это что-то лежит в основе) В основе лежит выживание и размножение. Да, я сторонник эволюционной психологии, т.к. это слишком логично и нечем крыть) Старший брат в действительности боится потерять ресурсы от родителей и не выжить... Начальник боится, что амбициозный специалист займет его место и не выживет... Локео боится, что домиленд поглотит рынок загородки и ищет способы выделиться и сделать круто, т.к. если нет, то... не выживет. США боится, что развалится, поэтому ищет способы захватить рынки сбыта Европы. Ну вы поняли.
Все это не подается под таким соусом. Все это завуалируется за словами и не осознается, но это просто стратегия выживания. Страх - основной двигатель событий и историй.
Типология
Если в основе всего лежит выживание, то наше мышление должно работать по этому же принципу. Наш мозг - компьютер, сортирует категории данных по образам. Представьте себя в саванне у костра, на небе звезды, легкий ветер, слух напряжен. Из общения у вас только "у-у-у, а-а, гы-ра". Затрясся куст, выпрыгивает леопард и тяп за голову вашего другана Валеру и обратно в кусты). Трясущийся куст == Валера съеден. Я и Валера == человеки. Куст == Я съеден. Выбрать стратегию == бежать, если куст затрясется. Наш мозг раскидывает образы по категориям опасности/безопасности, полезности/бесполезности, удовольствия/неудовольствия.
Аналитика цифрового продукта
Возьмем пример: сделать возможность тарификации пропусков на территорию. Конфликт компании - грузовые машины тяжелые, ломают дорожное полотно, потеря ресурсов, необходимо компенсировать. Бьём категории по принципу 1-0: Один тариф / Много тарифов, Всегда платный / По выбору. Смотрим как эти категории дружат с категориями других объектов: пропуска (постоянный, временный), товар (тариф / не тариф) и т.д. Мы получили кости функции продукта, на которые можно наращивать данные, дающие базовую потребность и формировать процесс. Пошли от бизнес потребности, от конфликта и истока существования бизнеса как живого организма, поэтому фичу будет просто продать.
Жду какашки или огонечки))
5АМ | #стартап
В долгосрочную перспективу меня очень интересует сценаристика в связке с геймдевом, поэтому я начал прокачиваться в написании сценария. В сценарии очень строгая структура. Сценарист рассказывает историю. История рассказывается через призму события. Событие - это всегда изменение состояния героя. Событие проявляется через конфликт: восстановить разрушенные отношения с отцом, получить работу мечты, добиться отношений с девушкой/парнем, которой недостоин/недостойна, спасти мир в конце концов. Все это укладывается в кадр, сцену, акт, эпизод. В последнем происходит кульминация изменения - решение конфликта.
Вся наша жизнь: вчерашний день, прошлый год - это тысячи историй. История не может быть без конфликта, иначе она не будет интересна. Меня заинтересовала тема конфликта как абстракция. Что такое конфликт? Если он лежит прям в корне, значит это можно хакнуть и использовать в работе и развитии продуктов, интерфейсов.
Конфликтология
Есть даже наука конфликтология. В корне любого конфликта любого уровня лежит борьба и всегда за ресурсы. Тут не обойтись без примеров. Старший брат видит как младшему брату достаётся больше внимания и начинает отвешивать лещей младшему. Недалекий начальник подставляет нового амбициозного подчиненного специалиста. Наш сервис Локео делает нишевые фичи для загородного рынка, чтобы конкурировать с Домилендом. США в 1920-х как развитое государство с кризисом перепроизводства на континенте, на котором уже некому продавать товары.
Что объединяет все эти конфликты? Что-то одно. Если это что-то объединяет историю, которая и есть наша с вами жизнь, то это что-то лежит в основе) В основе лежит выживание и размножение. Да, я сторонник эволюционной психологии, т.к. это слишком логично и нечем крыть) Старший брат в действительности боится потерять ресурсы от родителей и не выжить... Начальник боится, что амбициозный специалист займет его место и не выживет... Локео боится, что домиленд поглотит рынок загородки и ищет способы выделиться и сделать круто, т.к. если нет, то... не выживет. США боится, что развалится, поэтому ищет способы захватить рынки сбыта Европы. Ну вы поняли.
Все это не подается под таким соусом. Все это завуалируется за словами и не осознается, но это просто стратегия выживания. Страх - основной двигатель событий и историй.
Типология
Если в основе всего лежит выживание, то наше мышление должно работать по этому же принципу. Наш мозг - компьютер, сортирует категории данных по образам. Представьте себя в саванне у костра, на небе звезды, легкий ветер, слух напряжен. Из общения у вас только "у-у-у, а-а, гы-ра". Затрясся куст, выпрыгивает леопард и тяп за голову вашего другана Валеру и обратно в кусты). Трясущийся куст == Валера съеден. Я и Валера == человеки. Куст == Я съеден. Выбрать стратегию == бежать, если куст затрясется. Наш мозг раскидывает образы по категориям опасности/безопасности, полезности/бесполезности, удовольствия/неудовольствия.
Аналитика цифрового продукта
Возьмем пример: сделать возможность тарификации пропусков на территорию. Конфликт компании - грузовые машины тяжелые, ломают дорожное полотно, потеря ресурсов, необходимо компенсировать. Бьём категории по принципу 1-0: Один тариф / Много тарифов, Всегда платный / По выбору. Смотрим как эти категории дружат с категориями других объектов: пропуска (постоянный, временный), товар (тариф / не тариф) и т.д. Мы получили кости функции продукта, на которые можно наращивать данные, дающие базовую потребность и формировать процесс. Пошли от бизнес потребности, от конфликта и истока существования бизнеса как живого организма, поэтому фичу будет просто продать.
Жду какашки или огонечки))
5АМ | #стартап
Вы же знаете про MVP: быстро сделал, проверил гипотезу и вперед, к клиенту. В IT-поп фантастике можно услышать: ты такой зашел, кинул гипотезу, сварганил приложеньку и ходишь по Тверской-Ямской пристаёшь типа "нате, холосо? купите?🤓")
В память впечатывается "MVP == быстро", желательно за месяц, желательно за 100к рублей.
Вот мы пилим Локео уже два года с момента прям отвратительных прототипов. И как бы больно не было, но я понимаю, что текущий релиз Локео, который мы начали внедрять, это все еще MVP. И сейчас в чистке и рефакторинге мы приводим его к формату вылизанного продукта.
Минимальный жизнеспособный продукт. Он минимальный, блин, для каждой ниши по-своему. Для клиентов в загородке минимально - это финансовая система с кучей фичей и микроопераций с тремя интеграциями, 8 автоматических физических КПП, пропускная система с автоматикой и интеграцией со СКУД. Желательно еще систему обращений, голосований и новостей, но тут уже можно хотя бы продать со скрипом. То есть, чтобы просто удовлетворить минимальные потребности нужно 2 года, Карл. 2 года деньги жечь.
Все это к чему. Наступает эра всевозрастающей сложности систем.
Это происходит из-за того, что первый слой систем, которые закрывают базовые потребности, уже весь окучили. Потребность возникает уже в связи нескольких систем, в синергии нескольких систем, в решении вопросов стыков систем. То есть, с каждым уровнем наслоения сложность разработки будет только увеличиваться. И там где "запихнуть радио в интернет" можно было за месяц-два, теперь уже можно за год-два. И то, огромными командами, бюджетами и полисом ДМС.🤑
5АМ | #стартап
В память впечатывается "MVP == быстро", желательно за месяц, желательно за 100к рублей.
Вот мы пилим Локео уже два года с момента прям отвратительных прототипов. И как бы больно не было, но я понимаю, что текущий релиз Локео, который мы начали внедрять, это все еще MVP. И сейчас в чистке и рефакторинге мы приводим его к формату вылизанного продукта.
Минимальный жизнеспособный продукт. Он минимальный, блин, для каждой ниши по-своему. Для клиентов в загородке минимально - это финансовая система с кучей фичей и микроопераций с тремя интеграциями, 8 автоматических физических КПП, пропускная система с автоматикой и интеграцией со СКУД. Желательно еще систему обращений, голосований и новостей, но тут уже можно хотя бы продать со скрипом. То есть, чтобы просто удовлетворить минимальные потребности нужно 2 года, Карл. 2 года деньги жечь.
Все это к чему. Наступает эра всевозрастающей сложности систем.
Это происходит из-за того, что первый слой систем, которые закрывают базовые потребности, уже весь окучили. Потребность возникает уже в связи нескольких систем, в синергии нескольких систем, в решении вопросов стыков систем. То есть, с каждым уровнем наслоения сложность разработки будет только увеличиваться. И там где "запихнуть радио в интернет" можно было за месяц-два, теперь уже можно за год-два. И то, огромными командами, бюджетами и полисом ДМС.
5АМ | #стартап
Please open Telegram to view this post
VIEW IN TELEGRAM
Фича-паразит
Интересный феномен: Фича-паразит. Она использует существующий раздел/сущность данных, чтобы выполнить свою функцию. Она появляется, когда мы расширяем наш продукт для решения других проблем.
Допустим, у нас уже есть раздел "клиенты". Он был добавлен для решения проблемы нашего пользователя в рамках гипотезы "А". Чтобы добавить "клиента", пользователь проходит определенные шаги. Набор данных строго обозначен. Фичи поставлены.
Но спустя время мы пытаемся решить другую проблему, которая повлияет на метрики. Формируем гипотезу, строим процесс и видим, что в раздел "клиенты" требуется добавить еще данные, чтобы общий процесс заработал. Допустим требуется, чтобы при добавлении "клиента" пользователь выбрал определенный "тип" клиента в дропдауне и установил чек-бокс.
Что происходит в этот момент:
- возможность "создать клиента" раздваивается на две версии, каждая из которых влияет на разные процессы (job-ы). Значит нужно править документацию, отрезая версию для этой процедуры
- если произошло расщепление на версии, то в макетах тоже нужно развести эти процедуры. На уровне макетов появляются состояния и дизайнеру нужно исправить как базовую версию, чтобы отразить новые дропдаун и чек-бокс и новую версию с прожатыми данными.
- дропдаун и чек-бокс становятся необязательными данными, нам нужно исключить их из валидации, т.е. бэк и фронт должны это учесть.
- если данные необязательны, то их нужно по-особому объяснить клиенту в UX или текстах.
- ситуация осложняется, если для выполнения общего процесса требуется добавить несколько таких фич в разные сущности.
Причем уйти от этого никак нельзя на основании бритвы Оккама. Думаю каждый из вас встречался с подобным.
Есть помощь. Фича-паразит боится колдовства. Нужно произнести заклинание "АНАХУАЭТОНУЖНО"😄 И чаще смотреть вдокументацию "книгу Заклинаний".
5АМ | #стартап
Интересный феномен: Фича-паразит. Она использует существующий раздел/сущность данных, чтобы выполнить свою функцию. Она появляется, когда мы расширяем наш продукт для решения других проблем.
Допустим, у нас уже есть раздел "клиенты". Он был добавлен для решения проблемы нашего пользователя в рамках гипотезы "А". Чтобы добавить "клиента", пользователь проходит определенные шаги. Набор данных строго обозначен. Фичи поставлены.
Но спустя время мы пытаемся решить другую проблему, которая повлияет на метрики. Формируем гипотезу, строим процесс и видим, что в раздел "клиенты" требуется добавить еще данные, чтобы общий процесс заработал. Допустим требуется, чтобы при добавлении "клиента" пользователь выбрал определенный "тип" клиента в дропдауне и установил чек-бокс.
Что происходит в этот момент:
- возможность "создать клиента" раздваивается на две версии, каждая из которых влияет на разные процессы (job-ы). Значит нужно править документацию, отрезая версию для этой процедуры
- если произошло расщепление на версии, то в макетах тоже нужно развести эти процедуры. На уровне макетов появляются состояния и дизайнеру нужно исправить как базовую версию, чтобы отразить новые дропдаун и чек-бокс и новую версию с прожатыми данными.
- дропдаун и чек-бокс становятся необязательными данными, нам нужно исключить их из валидации, т.е. бэк и фронт должны это учесть.
- если данные необязательны, то их нужно по-особому объяснить клиенту в UX или текстах.
- ситуация осложняется, если для выполнения общего процесса требуется добавить несколько таких фич в разные сущности.
Причем уйти от этого никак нельзя на основании бритвы Оккама. Думаю каждый из вас встречался с подобным.
Есть помощь. Фича-паразит боится колдовства. Нужно произнести заклинание "АНАХУАЭТОНУЖНО"😄 И чаще смотреть в
5АМ | #стартап
Глубинные интервью
Закину пару идей про качественные исследования в рамках бизнес и системного анализа. Рассказываю с позиции, когда продукта нет.
Продакт подтвердил наличие нерешенных потребностей, перевел и оформил их в понятный запрос пользователя, например, "Мне нужно удаленно подписывать кадровые документы, чтобы сэкономить на бумаге и логистике".
Закинул продуктовую гипотезу: "Если создать приложение для сотрудника HR отдела и приложение для кандидата, в котором будет процесс подготовки, загрузки и подписания документа с помощью усиленной неквалифицированной подписи с интеграцией с 1С, то это будет легитимно и не потребуется печатать доки и отправлять их СДЭК-ом. Это сэкономит ему деньги, поэтому он захочет купить наш продукт". Подготовил высокоуровневые требования к ней и описания.
Далее начинается интересное. Нужно выявить существующий процесс и существующие среды. BA/SA вступают в бой, ну или продакт в этой роли) Три этапа: подготовка, интервью, оформление.
Подготовка
Как сказал мой дед:я твой дед "Победа любит подготовку". Нужно заранее изучить предметную область, понятийный аппарат, имеющиеся среды обработки данных, участвующих лиц, подготовить список тупых вопросов. Например, узнать, что в цепочке участвуют: HR, кандидат, бухгалтер, курьер. Среды: 1С, excel, doc, может быть CRM hr-a.
Важно понимать и помнить свою цель, иначе вас могут увести далеко от сути в глубокие нюансы. Чтобы понять цель, нужно и в своих процессах использовать подход системного анализа. Какие данные вам нужно собрать, чтобы ваши процессы потекли ручейком. Задача собрать центральный процесс, который приведет к результату, обозначенному в гипотезе продактом. Из процесса выявить набор сущностей данных. Из сущностей выявить все данные, которые необходимы процессу в рамках конкретной сущности. Из данных выявить основные и второстепенные операции/процедуры. И далее им уже задать требования.
Понимая весь процесс, идем к пользователю.
Интервью
По моему опыту нет лучше вопроса на интервью, который запускает выдачу данных, чем "Что вы, Тамара Григорьевна, делаете каждый день?" или "Что ты, серверная стойка с ПО, делаешь каждый день тут?". Остальное дело техники: задавать открытые вопросы, не перебивать, наводящими вопросами возвращать в нужное вам русло.
Почему именно этот вопрос. Постановка этого вопроса запускает конкретный и понятный образ в голове, человек вспоминает что он берет в руку, какие вкладки и файлы открывает, с какими данными работает. Мы сразу начинаем видеть его глазами и буквально идем по его процессу.
В рамках общения воспроизводится центральный процесс, сразу видим набор сущностей и данных к ним, получаем материалы для будущего мозгового штурма, чтобы сформировать уже операции будущего продукта и требования к ним.
Оформление
Начинаем креативить процесс, про методы креатива писал тут. Тема оформления обширная. Обязательно раскрою. Но именно оформление СА позволяет продакту и проджекту оценить стоимость продукта и сроки его поставки, поэтому подготовленные им данные должны бесшовно встраиваться в разработку.
5АМ | #стартап
Закину пару идей про качественные исследования в рамках бизнес и системного анализа. Рассказываю с позиции, когда продукта нет.
Продакт подтвердил наличие нерешенных потребностей, перевел и оформил их в понятный запрос пользователя, например, "Мне нужно удаленно подписывать кадровые документы, чтобы сэкономить на бумаге и логистике".
Закинул продуктовую гипотезу: "Если создать приложение для сотрудника HR отдела и приложение для кандидата, в котором будет процесс подготовки, загрузки и подписания документа с помощью усиленной неквалифицированной подписи с интеграцией с 1С, то это будет легитимно и не потребуется печатать доки и отправлять их СДЭК-ом. Это сэкономит ему деньги, поэтому он захочет купить наш продукт". Подготовил высокоуровневые требования к ней и описания.
Далее начинается интересное. Нужно выявить существующий процесс и существующие среды. BA/SA вступают в бой, ну или продакт в этой роли) Три этапа: подготовка, интервью, оформление.
Подготовка
Как сказал мой дед:
Важно понимать и помнить свою цель, иначе вас могут увести далеко от сути в глубокие нюансы. Чтобы понять цель, нужно и в своих процессах использовать подход системного анализа. Какие данные вам нужно собрать, чтобы ваши процессы потекли ручейком. Задача собрать центральный процесс, который приведет к результату, обозначенному в гипотезе продактом. Из процесса выявить набор сущностей данных. Из сущностей выявить все данные, которые необходимы процессу в рамках конкретной сущности. Из данных выявить основные и второстепенные операции/процедуры. И далее им уже задать требования.
Понимая весь процесс, идем к пользователю.
Интервью
По моему опыту нет лучше вопроса на интервью, который запускает выдачу данных, чем "Что вы, Тамара Григорьевна, делаете каждый день?" или "Что ты, серверная стойка с ПО, делаешь каждый день тут?". Остальное дело техники: задавать открытые вопросы, не перебивать, наводящими вопросами возвращать в нужное вам русло.
Почему именно этот вопрос. Постановка этого вопроса запускает конкретный и понятный образ в голове, человек вспоминает что он берет в руку, какие вкладки и файлы открывает, с какими данными работает. Мы сразу начинаем видеть его глазами и буквально идем по его процессу.
В рамках общения воспроизводится центральный процесс, сразу видим набор сущностей и данных к ним, получаем материалы для будущего мозгового штурма, чтобы сформировать уже операции будущего продукта и требования к ним.
Оформление
Начинаем креативить процесс, про методы креатива писал тут. Тема оформления обширная. Обязательно раскрою. Но именно оформление СА позволяет продакту и проджекту оценить стоимость продукта и сроки его поставки, поэтому подготовленные им данные должны бесшовно встраиваться в разработку.
5АМ | #стартап
Типы стартапов
Хочу поделиться с вами моей типизацией стартапов. Стартап максимально гибкая конструкция, которая при наличии определенных компонентов может неожиданно вылететь на рынок и изменить ход игры. Я где-то встречал фразу: "инвестируют в то, что не понимают. То, что понимают - финансируют." Так что основа типизации - откуда и какие деньги)
🟣 Уверовавшие
Как правило это молодые (очень) люди, очень заряженные, с шилом в заднице, верящие в святое и чистое предпринимательство. Они ищут идею повсюду, чтобы быстро её запаковать, найти CTO и запитчить на инвесторских мероприятиях. Питчить нужно много, постоянно, повсюду. Для них главное знакомство, нужно много-много бегать кабанчиком и рассказывать про идею. Они пытаются найти инвестиции, но даже не представляют как строить организацию, систему. Предполагают, что наймут "правильных" людей, которые все сделают, потому что они знают как делегировать. Откуда деньги: только от инвесторов, которые, по их мнению, должны почему-то дать деньги, но чаще родственники или, что еще страшнее, личные накопления. Шанс 1 из 100, потом уходят в продакты или ПМ-ы.
🟣 Тихони
Просто, тихо, мирно, никого не оповещая, взял и херак - Minecraft. В этом типе у человека или команды есть глубокие компетенции и, как правило, это просто фан, а не бизнес, но постепенно рождается что-то уникальное, что вдруг начинает заходить пользователям. Крайне редкий вариант, но и палка раз в год стреляет. Откуда деньги: личные накопления, кредитные, далее первые продажи и уже после набора фан базы - инвестиционные. Шанс все так же 1 из 100.
🟣 Придаток
Вот тут где-то начинается реальность. Собственники бизнеса в реальном секторе, имеющие и знающие процессы. Видят и глубоко понимают проблему рынка через общение с конкурентами или партнерами по сектору. Стартап фомируется внутри бизнеса и постепенно рождается в самостоятельное юридическое образование. Важным компонентом является прямое влияние стартапа на стратегию развития и выживания "кормящего" бизнеса, поэтому скорость выхода на рынок менее важна, так как есть "ответственность" перед основным бизнесом. Главная сложность - это партнерство, человек, ведущий стартап, который по сути должен построить с нуля технологический бизнес. Деньги у придатка непрофильные, т.е. инвестируют организация или лицо, не знающая как построить бизнес в IT со всеми нюансами разработки, продаж, тех. поддержки и т.д. Шанс выше, но отсутствие опыта может прибить плитой, 10 из 100.
🟣 Жирные
Специалисты-звезды, топ-менеджеры, команды сработавшихся лидов, вышедшие из конкурентного бизнеса, имеющие связи с быстрым выходом к инвест фондам. Их модель ясна, коротко их питч: вот мы, мы можем, мы знаем, особо ничего не придумываем, повторяем + вишенка, будет много... много денег... потом, нужно много... много денег.... сейчас, дайте. Как правило ответ - хорошо, нате (я не выдумываю - вот). Инвестиции, как правило, профильные сразу, а это значит, что помимо денег полетят сразу ништяки защиты инвестиций: юристы, бухгалтеры, финансовое управление, маркетинг, лучшие бизнес процессы управления проектами, продаж и т.д. Каждый пук-чих оплачивается, стартап в масле. Именно от них чаще всего слышно, что нужно продавать как можно раньше, что нужен максимум кастдевов, cjm-ов, jtbd-вов, офис в центре, массажист, дмс и личный бариста) Шансы гораздо выше, если фаундеры (именно тут они называются так) все таки будут работать, 20 из 100.
5АМ | #стартап
Хочу поделиться с вами моей типизацией стартапов. Стартап максимально гибкая конструкция, которая при наличии определенных компонентов может неожиданно вылететь на рынок и изменить ход игры. Я где-то встречал фразу: "инвестируют в то, что не понимают. То, что понимают - финансируют." Так что основа типизации - откуда и какие деньги)
🟣 Уверовавшие
Как правило это молодые (очень) люди, очень заряженные, с шилом в заднице, верящие в святое и чистое предпринимательство. Они ищут идею повсюду, чтобы быстро её запаковать, найти CTO и запитчить на инвесторских мероприятиях. Питчить нужно много, постоянно, повсюду. Для них главное знакомство, нужно много-много бегать кабанчиком и рассказывать про идею. Они пытаются найти инвестиции, но даже не представляют как строить организацию, систему. Предполагают, что наймут "правильных" людей, которые все сделают, потому что они знают как делегировать. Откуда деньги: только от инвесторов, которые, по их мнению, должны почему-то дать деньги, но чаще родственники или, что еще страшнее, личные накопления. Шанс 1 из 100, потом уходят в продакты или ПМ-ы.
🟣 Тихони
Просто, тихо, мирно, никого не оповещая, взял и херак - Minecraft. В этом типе у человека или команды есть глубокие компетенции и, как правило, это просто фан, а не бизнес, но постепенно рождается что-то уникальное, что вдруг начинает заходить пользователям. Крайне редкий вариант, но и палка раз в год стреляет. Откуда деньги: личные накопления, кредитные, далее первые продажи и уже после набора фан базы - инвестиционные. Шанс все так же 1 из 100.
🟣 Придаток
Вот тут где-то начинается реальность. Собственники бизнеса в реальном секторе, имеющие и знающие процессы. Видят и глубоко понимают проблему рынка через общение с конкурентами или партнерами по сектору. Стартап фомируется внутри бизнеса и постепенно рождается в самостоятельное юридическое образование. Важным компонентом является прямое влияние стартапа на стратегию развития и выживания "кормящего" бизнеса, поэтому скорость выхода на рынок менее важна, так как есть "ответственность" перед основным бизнесом. Главная сложность - это партнерство, человек, ведущий стартап, который по сути должен построить с нуля технологический бизнес. Деньги у придатка непрофильные, т.е. инвестируют организация или лицо, не знающая как построить бизнес в IT со всеми нюансами разработки, продаж, тех. поддержки и т.д. Шанс выше, но отсутствие опыта может прибить плитой, 10 из 100.
🟣 Жирные
Специалисты-звезды, топ-менеджеры, команды сработавшихся лидов, вышедшие из конкурентного бизнеса, имеющие связи с быстрым выходом к инвест фондам. Их модель ясна, коротко их питч: вот мы, мы можем, мы знаем, особо ничего не придумываем, повторяем + вишенка, будет много... много денег... потом, нужно много... много денег.... сейчас, дайте. Как правило ответ - хорошо, нате (я не выдумываю - вот). Инвестиции, как правило, профильные сразу, а это значит, что помимо денег полетят сразу ништяки защиты инвестиций: юристы, бухгалтеры, финансовое управление, маркетинг, лучшие бизнес процессы управления проектами, продаж и т.д. Каждый пук-чих оплачивается, стартап в масле. Именно от них чаще всего слышно, что нужно продавать как можно раньше, что нужен максимум кастдевов, cjm-ов, jtbd-вов, офис в центре, массажист, дмс и личный бариста) Шансы гораздо выше, если фаундеры (именно тут они называются так) все таки будут работать, 20 из 100.
5АМ | #стартап