📋 Лайфхак по созданию брифа 📋

Если нет времени составлять бриф для клиента (особенно, под специфичную систему), делаете одно из двух:

1. Идете на сайты крутых студий, скачиваете брифы.
2. Звоните в одну из студий, притворяетесь вашим клиентом (без обозначения названия фирмы), рассказываете про систему и просите прислать бриф под вас.

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

Profit 💰

🎥 Воркшоп 💌 "Секси чат" 💌 Часть 2-я 🎥

В 20:00 начнется воркшоп

Вы можете посмотреть его по ссылке:

https://youtu.be/iunYHcV1GOQ

Если хотите присоедениться, то переходите в 🎩 Клуб 🎩 и ищите ссылку на воркшоп

🗞 Новости 25-го октября 🗞

Видео: https://youtu.be/VFe2Do3vqRo

🏋️‍♂️ Новый формат Тренировок 🏋️‍♂️

Тестовые созвоны по Тренировкам показали их несостоятельность, поэтому мы переходим к новому формату:

Полноценный ежемесячный 3-х дневный хакатон!

Всю информацию вы можете почитать на новой странцие 🏋️‍♂️ Тренировок 🏋️‍♂️


🎓 Первые курсы 🎓

А еще стало понятно, что никому ничего непонятно (и это нормально)

Поэтому было принято решение, что для начала я соберу курс по проектированию, который даст ответы на все вопросы про проектирование IT-проектов с нуля

Почитать о курсе можно на странице 🎓 Курс «Как создать IT-проект и не про💣баться»

Часть людей, которые активно проявляли себя на Тренировках, получат курс бесплатно 🎉

Также, если вы считаете, что тоже заслужили бесплатный курс, обязательно напишите мне @davidshekunts

🔑 Ключ к тому, чего не существует 🔑

Первое и самое важное, когда вы проектируете совершенно новую систему:

“Изучите максимальное количество систем схожих систем”

Конкуренты – продукты, которые “отнимают” вашего пользователя на текущем рынке

Аналоги – продукты, которые выполняют туже функцию, но находяться в других рынках, поэтому ваши клиенты не пересекаются

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

Самая интересная здесь штука – это референсы.

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

Во-вторых, референсы могут быть из абсолютно другой сферы и иметь совершенно другую ЦА, главное, чтобы они решали свои задачи схожей с вами моделью

Например, вы хотите создать приложение “коучинга для предпринимателей”, в котором они могут (1) получать полезные новости из их области, (2) проходить составленные под них уникальные домашние задания и (3) получать платные консультации через чат.

Если вы не нашли “конкурентов” / “аналоги”, найдите несколько разных приложения, которые по отдельности содержат функционал “новостной ленты” (vk), “выполнение домашних заданий” (сoursera app) и “чат с платными консультациями” (sanctuary) и исплозуйте их как ориентир.

А вот на что именно и как смотреть на конкурентов, аналоги и референсы вы узнаете в готовящемся курсе "Как создать IT-проект и не про💣баться"

👨🏻 Обо мне, чтобы ответить на вопросы: "А что это за усатый черт?"

λ ФОП – функциональная альтернатива ООП для мультипарадигмальных языков

🛌 FDD – набор best-practice заветов по архитектуре и разработке современных backend приложений для ленивых.

По всем вопросам писать @davidshekunts 🖤

———

🌳 ДАП – Дерево анализа проекта (альфа-версия) 🌳

Выпустил просто гигантский материал на тему того: “Как проанализировать чей-то бизнес или идею”

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

А бизнес-анализ – это первый и самый важный этап для успешного проектирования любого (и особенно крупного) IT-продукта

Читайте, наслаждайтесь: https://davidshekunts.ru/2020/11/01/dap-derevo-analiza-proekta-alfa-versiya/

Обязательно комментируйте и пишите мне в ЛС, там нужно еще много чего уточнить, поправить и привести примеры с ссылками (поэтому пока alpha)

#architecture #проектирование

🕸 Как рождаются и почему работают системы 🕸

В начале моей карьеры меня интересовало: “как и зачем появился MVC, MVVM, DDD, Clean Architecture и другие архитектурные паттерны? А главное, почему это работает?”

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

Я нашел ответ и самое крутое, что он относиться к абсолютно любым системам: лекарства, науки, дисциплины, все что может определяться как “методологи”, etc.

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

Поэтому, если правильно взвесить требования и условия, подобрать под них готовую систему и начать следовать ее правилам, есть большой шанс, что она будет как минимум “приемлемой”

Да не “идеальная”, но задачи решать вы сможете

И так до момента пока задачи не кончаться или придет время подбирать и использовать новую систему под изменившиеся условия

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

А урок тут следующий:

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

Но, скорее всего, вы обнаружите, что подходящая система под ваши условия уже есть (вы в 99% случаев не уникальны), ее осталость только немного подштриховать под вашу ситуацию

#architecture #проектирование

🏚 -> Хотите масштабируемую систему? -> 🏰

Системы состоят из:

. Знания – какой-то набор скомпонованных данных, отражающих состояние какого-то понятия / объекта (“Заказ” в интернет-магазине)

. Действия – действия над Знаниями, чаще всего это или CRUD (“получить список Заказов”), или более комплексный набор действий, который производит много CRUD (“оформить Заказ”)

. События – данные, оповещающие о фактах (всегда глагол и всегда в прошлом времени), произошедших в системе над Знаниями во время Действий (при оформлении: “изменился статуса Заказа”, “сформирована накладная в системе доставки”, “произведена оплата”, etc.)

Если про первые 2 понятия присутствуют в любой программе, то про 3-е все успешно забывают, а оно не менее (а часто более) важно!

Ведь именно События позволяют:

1. Разбивать систему на небольшие независимые куски, реагирующие на события друг друга

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

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

4. etc.

Это сейчас относиться не только к backend или frontend, так можно писать даже библиотеки

О том, как работать с Событиями гуглите:

. DDD Domain и Application Events
. Event Driven Architecture
. Saga pattern
. Orchestration vs Choreography

Ну, или поставьте 15 классов (👌), тогда я сделаю воркшоп на эту тему

———

☠️ 4 всадника «Требования» ☠️

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

https://davidshekunts.ru/2020/11/30/4-vsadnika-trebovaniya/

Спойлер: Требование = Потребность + Проблема (с оценкой боли) + Ожидание (DoS) + Факт завершенности (DoD)

———

Кстати, контента и активности нет, потому что я 6-ю неделю болею короной… Когда поправлюсь, тогда все опять активизируем

🔥 АХУITЕЛЬНЫЕ НОВОСТИ 🔥

Короче, если не будет технических проблем, где-то в 21:00 по мск я выйду в онлайн эфир с новым крутым форматом

Готовьте YouTube, Miro и Telegram

Ссылка будет доступна в канале 🎩 Клуба 🎩 IT-Качалки 💪 (как попасть)

🎥 ГО ГО ГО 🎥

Стрим – https://youtu.be/IwNMQ4QdnPY

⛏ Вакансия: QA Engineer ⛏

Моему замечательному коллеге в команду нужен QA уровня middle-senior (который хочет расти в менеджмент) или не успевший ахуеть в край lead

Вакансия: https://hh.ru/vacancy/40640115

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

Если что, можете писать в hh с пометкой “своячество – зло” или мне в личку, я вас направлю

⚖️ Адвокат клиента ⚖️

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

- Изучать потребности текущих и потенциальных клиентов
- Их недовольство предоставляемыми продуктами
- Изучение рынка
- Формирование из всего вышесказанного карты развития продукта

Во многих фирмах эту роль на себя берет CEO / CPO / Product Manager / Product Owner

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

Например, у вас настолько разные клиенты (B2B + B2C, клиенты из разных стран или рынков, etc.), что на роль "адвоката" какого-то типа клиента должен встать отдельный человек

Его роль можно назвать Client Owner / Lawyer

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

Градиент от Senior разработчика <-> Team Lead <-> CTO

Череда постов, в которых я размышляю над различиями этих ролей

Сразу договоримся о правилах:

1 роль != 1 человек – 1 человек может находиться сразу в N (нескольких) ролях

1000 и 1 полутон – границы всегда размыты и области одной роли будут пересекаться с другой

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

Для чего эта информация? Я думаю, что во многом даже для того, чтобы отвадить некоторых людей от становления, например, CTO 🙂 Потому что там все не так сладко, как многим кажестя

Если же наоборот эта информация преисполнит вас интересом и мужеством, то я тоже буду считать свою миссию выполненной

Ставьте классы (👌), если тема для вас интересная и я на следующей неделе начну выпускать посты

🥋 Приемы результативности 🥋

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

1. Планирование – самая важная составляющая любой деятельности.

2. План = Точка "А" → Набор действий → Точка "Б" (`function plan(A: point): point { // actions; return B;}`)

3. Самое важное в планировании – четкой определить точку "Б" (в цифрах, датах и фактах)

4. Самое важное после определения точки "Б" описать точку "А" (в таких же цифрах, датах и фактах)

5. Только со знанием точки "А" и точки "Б" можно приступать к планированию действий

6. Если что-то может выражаться конкретной цифрой или датой – это должно выражаться цифрой или датой

7. Ограничивать планирование нужно по времени ("буду планировать не более недели, а дальше начну с тем, что получилось"), а не качества (качество плана – слишком субъективная вещь, так никогда не закончишь)

8. Заранее поставьте отметки в плане, когда вы будете его пересматривать

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

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