Качество и Lean Startup

Сейчас среди стартапов модна идеология Lean — делать minimal valuable product, не заморачиваться над архитектурой, готовиться к тому, что проект — это тестирование бизнес-идеи на выживаемость, и возможно идея будет передумана, часть кода удалена, поэтому вкладывать много времени в доведение качества до 100% и в разработку супер-архитектуры невыгодно.

Кто работал в таких стартапах как аутстафф? Как вы относитесь к тому, что 100% качество не требуется, да и времени на 100% качество не даётся, не претит ли («не для того я 5 лет учился, чтобы теперь некачественно делать»)? Стоит ли программисту с нормальным образованием и 7+ лет полноценного опыта ввязываться в такое, или опытным — только в серьёзные проекты, а Lean Startup-ы должны писать студенты, «не царское это дело»?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я бы сказал, наоборот — как раз имея 7+ опыта есть шанс «вытянуть» потребности стартапа, где все быстро меняется и любое ошибочное решение через месяц может аукнуться очень больно.

Студентам проще учиться на больших стабильных проектах — никто не куда не спешит, у «старших» есть время на обучение и даже если сделал глупость, ее скорее всего выловит процесс — review/QA.

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

Простите, а разве вам надо «дополнительное время на качество»?

Пример: есть однотипные модули, в них есть общая функциональность, которую хорошо бы проанализировать и вынести в отдельное место (класс, модуль, неважно). Чтобы проанализировать существующие модули, выделить в них общее и вынести это общее, нужно дня два-три хотя бы (16-24 часов).
Тебя просят дописать ещё один модуль и даётся на него 24-32 часа. Анализировать и переписывать существующее «не нужно, раз работает — не трогаем», «нам всего лишь нужен ещё один модуль к следующей неделе». Но вынести общее хочется (code smell же), и понимаешь что ты поддерживаешь (расширяешь) некачественную структуру.
Разработка по скраму, т.е. в спринтах важно реализовывать user stories, а «мы улучшили архитектуру» это не user story, поэтому в скрам не вписывается.

А вот тут кроется несколько проблем.
1. Общая функциональность — архитектурный баг. Похожая функциональность — ещё не повод выносить её отдельно (очень часто потом оказывается, что функциональность таки не очень похожая, и по факту запиливается несколько реализаций в одном модуле/классе).

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

И да, по-моему опыту, обычно код протухает примерно так:
А добавлю-ка я ещё пару строчек в этот метод/класс =>
Ой, кажись название уже не очень соответствует функционалу, но не менять же название метода/класса по всему коду =>
Хрен его знает, что в этом модуле творится, пойду лучше свой напишу

Никакого отношения к скорости это не имеет.

Другий пункт — так, перший буває рідко, частіше код накопіпащений як у Some Developer зустрічається.

В шахматах, гроссмейстер 5 минутную партию сыграет тоже вполне качественно. Думаю, после 7+ лет оптыта, любое спагетти будет плавно пересекать в паттерны, архитектуру и тп.

Подписаться на комментарии