Что убивает большие проекты?
Недавно вспомнил один случай из жизни. В начале второго курса в универе договорились с другом совместно сделать аппку.
Тогда на хайпе была тематика здоровья, отслеживание всяких метрик по сну, сердцебиению и так далее. В общем, решили прям полноценно залететь на рынок со своим приложением для трекинга сна. Проект был реально большим, по итогу у нас было два приложения — для iOS и WatchOS.
В iOS приложении можно было отслеживать всю статистику по последнему сну, сколько времени ты спал, в каких фазах сна находился (мы даже написали свой алгоритм определения фаз сна) и много всего другого.
Для WatchOS мы запилили умный будильник, который трекал пульс пользователя во время сна и умел находить сбалансированный интервал времени для пробуждения.
На всё про всё ушло около 6 месяцев. И вот казалось бы — приложение готово, выкладывайте в стор, рубите миллионы.
Однако было два очень важных «но»:
1. Мы оба были крайне неопытными разрабами и написали всё без какой-либо расширяемой архитектуры и с кучей говнокода.
2. Мы оба не имели опыта запуска проектов, поэтому не понимали, как правильно это делать.
К чему привела композиция двух этих пунктов? О да, мы решили полностью переписать проект на нормальную архитектуру вместо того, чтобы выложить то, что есть и проверить гипотезу о том, что оно вообще имеет место на рынке, а рефакторить код уже в последствии в уже имеющемся проекте🥲
По итогу, к середине этого мега-рефакторинга, мы уже оба заметно выгорели с проекта и он по сути канул в Лету, хотя идейно и по имплементации первая версия была более чем юзабельной и годящейся для MVP.
Так вот, две морали сей истории:
1. Сводите проект к инкрементальным улучшениям. И даже отдельные итерации ставьте иногда под сомнение!
2. Изначально не упарывайтесь излишне в архитектуру и чистоту кода. Сначала проверьте, что ваша гипотеза вообще работает. Сделайте MVP и раскатите его как можно быстрее на пользователей!
К слову, плоды этого урока я неоднократно пожинал и на работе. Нередко менеджеры, да и другие разрабы бывают теми ещё максималистами и хотят видеть в реализации проекта всё и сразу.
Не стесняйтесь идти вразрез этому и пропагандировать итеративную разработку. Это даёт большее ощущение контроля над проектом, а также добавляет возможность чаще делать пит-стопы для анализа и более точечного рефакторинга написанного кода.
@engineering_path
Недавно вспомнил один случай из жизни. В начале второго курса в универе договорились с другом совместно сделать аппку.
Тогда на хайпе была тематика здоровья, отслеживание всяких метрик по сну, сердцебиению и так далее. В общем, решили прям полноценно залететь на рынок со своим приложением для трекинга сна. Проект был реально большим, по итогу у нас было два приложения — для iOS и WatchOS.
В iOS приложении можно было отслеживать всю статистику по последнему сну, сколько времени ты спал, в каких фазах сна находился (мы даже написали свой алгоритм определения фаз сна) и много всего другого.
Для WatchOS мы запилили умный будильник, который трекал пульс пользователя во время сна и умел находить сбалансированный интервал времени для пробуждения.
На всё про всё ушло около 6 месяцев. И вот казалось бы — приложение готово, выкладывайте в стор, рубите миллионы.
Однако было два очень важных «но»:
1. Мы оба были крайне неопытными разрабами и написали всё без какой-либо расширяемой архитектуры и с кучей говнокода.
2. Мы оба не имели опыта запуска проектов, поэтому не понимали, как правильно это делать.
К чему привела композиция двух этих пунктов? О да, мы решили полностью переписать проект на нормальную архитектуру вместо того, чтобы выложить то, что есть и проверить гипотезу о том, что оно вообще имеет место на рынке, а рефакторить код уже в последствии в уже имеющемся проекте🥲
По итогу, к середине этого мега-рефакторинга, мы уже оба заметно выгорели с проекта и он по сути канул в Лету, хотя идейно и по имплементации первая версия была более чем юзабельной и годящейся для MVP.
Так вот, две морали сей истории:
1. Сводите проект к инкрементальным улучшениям. И даже отдельные итерации ставьте иногда под сомнение!
2. Изначально не упарывайтесь излишне в архитектуру и чистоту кода. Сначала проверьте, что ваша гипотеза вообще работает. Сделайте MVP и раскатите его как можно быстрее на пользователей!
К слову, плоды этого урока я неоднократно пожинал и на работе. Нередко менеджеры, да и другие разрабы бывают теми ещё максималистами и хотят видеть в реализации проекта всё и сразу.
Не стесняйтесь идти вразрез этому и пропагандировать итеративную разработку. Это даёт большее ощущение контроля над проектом, а также добавляет возможность чаще делать пит-стопы для анализа и более точечного рефакторинга написанного кода.
@engineering_path