60 дней фильмов и сериалов
по промокоду:
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 04.06.2021 г. https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.

Как запускать проекты без жиры и прочей скукотени: вот наши главные принципы

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

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

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

безудержная радость команды перед запуском

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

Люди-винтики vs люди-механизмы

Менеджеры большинства ИТ-команд до сих пор строят их по принципам времён промышленной революции. Программисты ходят в офис или сидят в слеке с 9 до 18, ходят на дейли, работают по чётко прописанным ТЗ в Жире. Обычно они несут ответственность за время, которое -простояли за станком- просидели в IDE, а не за конечный результат.

труд на заводе в годы промышленной революции

Такие менеджеры забывают, что работа программиста часто творческая. Одну и ту же задачу можно решить «в лоб» и потерять на этом месяцы, а можно придумать элегантное решение, которое потребует пару недель, а потом в поддержке сэкономит годы. Большинство наших знакомых разработчиков постоянно занимаются саморазвитием — читают книги по профессии, ходят на конференции, ведут блоги, помогают коллегам. Они, может, и хотели бы больше думать головой, а не кодить таски из жиры, но привычный контекст мешает. Если вся тусовка в твоём баре рассказывает, как ходит на дейли, то хочешь или нет — сам туда пойдёшь.

Мы с Саматом отбираем в свои команды ребят, которым некомфортно в привычном контексте, которые хотят больше ответственности за результат. Такие программисты не любят оценивать задачи (читайте об этом подробнее здесь), часто пристают к бизнесу с неудобными вопросами и не требуют сложного обвеса в виде технический заданий, системных аналитиков, QA- и HR-менеджеров. Они не хотят быть винтиками — они хотят быть целым механизмом. На собеседованиях такие программисты обычно спрашивают об устройстве бизнеса и свободе в настройке CI, а не о печеньках и ДМС.

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

Оставайтесь маленькими

Команды больше 7 человек — это сложные системы, которые расходуют ресурсы не только на написание кода, но и на свое содержание. Чтобы не держать всё в голове, лидер нанимает тим-лидов, для экономии времени на найме и конфликтах — нанимает HR-менеджеров, а чтобы быть уверенным, что команда соблюдает правила игры — делает сложные флоу в Жире и заставляет менеджеров писать ТЗ.

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

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

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

Недостаток ресурсов

Начать фичу очень легко — можно просто написать команде письмо «теперь делаем Х». А вот сделать фичу, а тем более поддерживать её — тяжкий труд. Люди любят начинать и не любят доводить дела до конца. Даже в MVP. Вот и получаются к дедлайну продукты с хорошо продуманной регистрацией, валидацией форм, UI-китом, но с интерфейсными тупиками и без конкурентных преимуществ.

Самое хорошее средство от бесконечных начинаний — это недостаток ресурсов. Недостаток ресурсов не обязательно должен быть измеримым (не будем же мы эстимейтить таски на этапе MVP), это скорее вопрос ментального настроя людей, принимающих решения. Когда мы подключаемся к планированию MVP, мы стараемся переключить команду из режима «хорошо бы сделать Х» в режим «а мы точно не запустимся без Х?» или ещё лучше: «А какая минимальная функциональность должна быть у Х, чтобы мы запустились?».

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

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

Недельные планы и демо

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

В начале недели каждый программист дает простые обещания — какие полезные изменения в проекте он доделает за эти 5 рабочих дней.

примеры недельных обещаний. Какой кайф, что всё отмечено как «готово»!

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

Вот пример такого демо от нашего дорого фронтендера Бори

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

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

У нас настроен CI/CD, так что всё, что сделал программист, сразу же могут посмотреть другие члены команды, на живую. Вот как это работает:

почти все изменения оформляются как пул-реквесты в гитхабе

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

весь CI/CD у нас сделан на прекрасном CircleCI

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

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

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

«первым делом я поднимаю gitlab и sentry»

В ИТ, даже в начинающих компаниях, огородики цветут пышным цветом: люди заводят собственные гитлабы вместо (бесплатного!) гитхаба, разворачивают собственные версии sentry, youtrack, поднимают свои кластеры kubernetes ради двух подов. То есть вместо того, чтобы пойти и купить готовые сервисы за условные 5$ в месяц — городят свои огороды, которые, если посчитать полную стоимость владения (TCO), оказываются в разы дороже.

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

Федя как-то консультировал одну команду, которой достался грант Microsoft Azure для стартапов. Выданного гранта хватало как раз на две виртуалки, на одной из них ребята сделали прод, а на другой разместили огородики — gitlab, sentry, какие-то рассылали почты вроде postfix. Для CI мощностей одной виртуалки не хватало, поэтому ребята разместили воркеры на обоих тачках — надо ли говорить, что когда ребята много билдили, у них тормозил прод, а когда шла большая нагрузка на прод — не могли билдить?

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

Чтобы составить свой — начните с free-for.dev: это хороший каталог ресурсов, которые дают бесплатные лицензии для маленьких проектов. Бесплатность лицензий — не самое важное в этом сервисе, гораздо интереснее смотреть на таксономию и разбираться, какие инструменты автоматизации в принципе существуют в мире. К примеру когда-то именно оттуда я узнал, как работают APM (application performance monitoring) и автоматическое тестирование на удалённых мобилках а-ля BrowserStack.

Если вам было лень все это читать, вот основные принципы:

  1. Программисты, способные закрывать бизнес-задачи и спорящие о пользе с бизнесом, а не просто прогающие, что укажут;
  2. Желание оставаться маленькой командой как можно дольше;
  3. Недостаток ресурсов как механизм принятия правильных продуктовых решений;
  4. Еженедельные обещания программистов и видео-демо, которые они записывают с презентацией своей работы;

Всё это — жестко холиварные темы. Результата можно добиться и с заводом на 100 человек, которые делают задачи по 10-мегабайтным. DOC-файлам из жиры. Жира тоже работает, но это гроб гроб кладбище как скучно, к тому же, это медленнее, а значит — дороже. Дополнительная проблема завода — привычные правила игры создают чувство безопасности: «я делаю всё по правилам, плохой результат — не моя вина».

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

Вы программист и хотите работать с нами? Пишите Фёдору Борщёву на fedor@borshev.com.

Хотите заказать наши услуги? Пишите Самату Галимову, s@samat.me и @samatg в телеграме.

{ "author_name": "Федя и Самат", "author_type": "editor", "tags": [], "comments": 52, "likes": 32, "favorites": 133, "is_advertisement": false, "subsite_label": "life", "id": 143929, "is_wide": true, "is_ugc": false, "date": "Wed, 22 Jul 2020 12:19:51 +0300", "is_special": false }
0
52 комментария
Популярные
По порядку
Написать комментарий...
14

Программисты <...> работают по чётко прописанным ТЗ в Жире

Ответить
6

ну это менеджеры так считают, как в меме «how i see / how they see me»

Ответить
13

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

Ответить
2

Вопрос в приоритетах. 

Ответить
11

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

Ответить
2

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

Ответить
1

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

Ответить
0

ДМС - это не базовая потребность. Это услуга частных мед. клиник для среднего класса.

Ответить
8

Возникает сразу несколько вопросов.
1) Как вы понимаете что люди одинаково поняли задачу без описания требований? Как часто у вас происходят случаи, когда дизайнер задизайнил одно, фронтенд сверстал другое, а бек прислал в api третье?
2) Что вы предлагаете "людям-механизмам" чтобы они с вами работали? Я очень сильно сомневаюсь что много людей за одну зарплату готовы гореть продуктом и нести ответственность за что-то вне своей зоны ответственности.
3) Не кажется ли вам что опыт двухмесячного проекта недостаточно релевантый для того, чтобы подавать его как серебрянную пулю?

Ответить
3

1) дизайнер рисует макеты, бэк даёт документацию к API перед тем, как прогать все остальное. Такой проблемы не было 

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

3) ну мы тестировали все это не только два месяца :)

Ответить
0

1) Как пользоваться api понять проще всего, а вот когда его вызывать и как часто это уже другой вопрос и здесь больше всего расхождений происходит. Например у вас происходит какое-то обновление данных в фоновом режиме. Без подробного разбора и описания логики все поймут по разному.
2) Это кайфово первое время, а потом что? Интересные задачи и молодой коллектив все предлагают. Обычно активные работники хотят роста карьерного и финансового. Что вы с ними делаете в своей плоской структуре? Отпускаете делать свой стартап?

Ответить
5

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

Как я понимаю, основная идея — это работать с разработчиками с прокаченными софт-скилами, а хард-скилы (джун, мидл, сениор) — уже в процессе подтянутся. Или всё же не так? Сработает ли такой подход с командой, в которой не все прокаченные мидлы и сеньоры? 

Кто координирует разработчиков и помогает им выбрать обещания на неделю? Как вы организовывали этот процесс?

Ответить
5

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

Конечно, помогаем с обещаниями, если видим, что они нереалистичны. 

Ответить
2

А я таких программистов каждый день вижу и сам таким был.  А какой инструмент используете чтоб помочь с обещаниями? Ремень/Палка? )

Ответить
0

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

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

Ответить
0

=> Кто координирует разработчиков и помогает им выбрать обещания на неделю? Как вы организовывали этот процесс?

Есть такая должность бизнес-аналитик, без него - я хз как еще победить человеческую лень/междусобойчики и хитрожопость )

Ответить
2

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

Ответить
7

Потом задач будет больше 50 и вариант с notion они повторно перезапишут в ту самую Jira которую ругали ;)

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

Опсы будут поддерживать продукт, а т.к. issue tracker'а не было, то и предыдущий опыт считай что ушел в никуда.

Про базу знаний тоже ничего не написали.

«Сделал дело, слезай с тела» проект :)

Ответить
1

Э не, основная метрика нашего технического успеха - это простота изменений. Decoupled, strongly tested, вот это все. 

Ответить
1

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

Ответить
4

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

В остальном – «блокнот» придется все равно переводить в полноценный issue tracker.

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

Про базу знаний тоже не заметил упоминаний, может пропустил.

Jira которую поносили всю статью не виновата в том как ее используют люди. Бюрократия это не про инструменты.

Ответить
1

выдумал проблему, обосрал, выдумал решение - ок, люблю vc )

во всех этих историях про то как правильно имеет смысл руководствоваться отзывами заказчика, когда по факту продукт готов. Если продукт MVP - какие претензии?

Ответить
1

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

Насчёт ценности старых issue в трекере с точки зрения будущей отладки и изменений я хотел бы услышать классную историю успеха. Пока мой опыт в целом такой, что любая документация, кроме как в коде (тесты) очень быстро тухнет. Есть приятные исключения (обычно в плане API), но их очень мало. 

Ответить
0

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

Ответить
0

Для MVP может и избыточна, но почему бы сразу не писать задачи в issue tracker? В будущем все равно к этому придут. И необязательно же все фичи юзать.

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

Ответить
0

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

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

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

Вообще один дядька уже все описал для больших проектов, но "все её читали, но никто ей не следует" )

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

Ответить
0

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

Очень интересно будет прочесть ваш опыт про legacy и не-MVP проекты.

Ответить
3

А что записывают в видео-демо бэкендеры – пример работы запросов –, или QA-инженеры?

Ответить
1

бэкендеры запросики и какой-то минимальный PoC фронт

с QA сложнее!

Ответить
0

бэкендеры пишут тесты. написанные тесты доказательство сделанной работы. Задача без тестов == "не было сделано ничего"

Ответить
0

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

Ответить
0

У нас так:
– юнит и интеграционные тесты (видно ещё в CI/CD)
– скрины из постмана, что бекендер дёрнул ручку, подставил параметры, проверил ответ
– иногда бекендеры разворачивают у себя фронт и показывают интерфейс, что у них это работает

Только у нас это не на демо происходит, а в описании их пул-реквеста.

Ответить
3

Трамп ворвался на грядки неожиданно))

Ответить
3

Спасибо за статью, интересный опыт. Подписан и на Самата, и на Федора в телеграме. Очень нравится читать.

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

Что будет, если проблема пользователя придет в середине недели? Кто будет решать важная она или нет? Кто будет воспроизводить? Кто будет исправлять? Что будет с "обещанными задачами"?

Ответить
0

Любое внешнее воздействие — это повод пересмотреть обещания. Кажется вполне нормально сказать в среду «я не успеваю, потому что придумали более важную задачу». Главное — не делать так перед дедлайном.

Ответить
2

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

Ответить
0

Я там приложил скриншот реального списка задач в notion на запуске!

Где ставить задачи - не суть важно, главное - кто и как. Жира тут скорее прилагательное. 

Ответить
2

не удержался

Ответить
2

Спасибо за интересную статью!

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

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

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

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

Ответить
0

С тобой точно что-то не так, а именно:
1. Ты называешь коллег разрабами-винтиками. А ты разраб-винторез? Интересно увидеть твое CV и достижения.
2. Называешь системы взаимодействия в прибыльных компаниях "бюрократической системой". Расскажи про свой стартап и его метрики, очень интересно послушать.
3. Решаешь какие фичи запускать в MVP. Просто смешно.

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

Самат и Фёдор, благодаря вашей статье появился еще один IT единорог ломающий своим гигантским рогом устои IT.

Ответить
0

бомбит?

Ответить
1

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

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

Ответить
0

Короткий ответ: тестами! Если ты сломаешь предыдущую фичу - то узнаешь от этом в своём CI. Не все можно покрыть тестами, конечно. 

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

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

Ответить
1

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

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

В классическом подходе подразумевается, что у нас остается некая документация, которая как-то сводит вещи воедино. Что-то вроде описания "модель данных Х используется для .... форм для заполнения 4. Вот список кому где и как они доступны:..."

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

Грубо говоря, тратим время не на описание того, что только что сделали, а на обновление сведений в тот момент, когда они реально требуются?

Ответить
1

Почему у вас Трамп на заглавном фото?

Ответить
0

У этой фотки есть какая-то история, just google, но для меня это просто фотка бабки на даче. 

Ответить
1

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

Ответить
0

Bus factor он в первую очередь про тесты и нормальный код. 

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

Ответить
1

Это хорошо для какой то простой и весьма очевидной задачи.
Если проект большой и будет расти можно (да 109%) налететь на грабли позже.
Кто то что то сделал, оно работает, но позже подключить надо что то ещё и тут уже не будет, в итоге переписывать. И так раза 4.
Архитектура прописывается заранее и за неё отвечает 1 человек. Остальные имеют вольницу в рамках правил архитектуры, и все по несколько раз согласовывается.
Это про проект более чем три экрана и 10 фич.

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
Комментарии
null