Комментарии 11
Одна ошибка, которая может стоить корпорации миллионы, скорее всего корпорацию не убьёт. Такая же ошибка, стоящая жалкие тысячи, скорее всего убьёт стартап.
Корпорации потому и корпорации, что платят больше за собственную безопасность. Не задумывающийся об этом стартап корпорацией не станет. Свою ошибку найдёт.
Корпорации потому и корпорации, что платят больше за собственную безопасность. Не задумывающийся об этом стартап корпорацией не станет. Свою ошибку найдёт.
Причём, эти дорогущие проверки могут оказаться бесполезными. На данный момент мой Хром разучился запоминать место прокрутки страницы, и мне приходится каждый раз вручную прокручивать. И так уже неделю -_-
И знаете что? Это можно доверить им без опаски. Даже компании-покупателю было бы от этого только лучше: они бы не только ничего не сломали, а наоборот, сделали бы намного больше. Получается, что покупатель на самом деле получает худший результат за более высокую цену.
Какая-то наивность, как по мне. Две недели на тестирование изменений — не такой уж большой срок, в банковской сфере это может занимать месяцы и даже годы. Человеческий фактор есть всегда, и ошибку может допустить даже самый-самый матерый профи, поэтому задержки на ревью и тестирование просто необходимы для репутации фирмы.
Где-то точно подмена понятий в месте «мы дольше вылизывали продукт и поэтому вы получили худший результат, т.к. мы могли бы вместо этого кучу сырых фич накидать»
Что за детский сад написан в этой статье?
Если утром тебя вдруг посетила идея о чем-то новом, ты можешь написать ее и протолкнуть на рабочие серверы уже к обеду.
Забавно будет дать такому герою какую-нибудь гигантскую систему в несколько миллионов строк кода и посмотреть, как он там запилит что-нибудь за несколько часов и протолкнёт это дело на продакшн с миллионами посетителями и ничего нигде и никому в итоге не поломает.
Когда они были независимые, они могли вносить изменения мгновенно. Теперь, по их словам, две недели это минимальный срок за который они могут запустить новый код в работу… Когда я спросил их, поменяли бы они 10% от суммы, заплаченной при приобретении, на возможность мгновенного запуска новых кодов в работу, все трое сразу согласились… Они сказали, что не хотят об этом даже думать, боясь зайти слишком далеко, но я чувствую, что они бы отдали до 50 процентов.
Ну и чего эти сопливые нытики всё продолжают сидеть и работать со своим таким нехорошим нынешним владельцем? Пусть пойдут и сделают что-нибудь, напишут например хотя-бы начальству о своём желании избавиться от 50% своей прибыли ради свободы. Пусть увольняются и продолжают заниматься мелкими стартапами, а серьёзные дела пусть оставят более терпеливым и усердным коллегам.
Вы вырвали первый пункт из контекста и спорите с самим собой. Речь именно о стартапе.
И это, действительно, так. По крайней мере, те стартапы (вебервисы/вебприложения), где мне посчастливилось работать, соответсвовали этому. Можно релизить на прод так часто, как только ты этого хочешь. Потому что минимальна стоимость как самих фич, так и по сути, стоимость возможных краткосрочных фейлов на проде (на начальном этапе). Что, естественно, невозможно в случае более крупной и стабильной кампании с регламентированным процессом разработки, планирования и поставки.
Для таких прелесть работы в стартапах именно в отсутствии массы проверок при выпуске продукта. В настоящих стартапах нет внешних проверок вообще. Если утром тебя вдруг посетила идея о чем-то новом, ты можешь написать ее и протолкнуть на рабочие серверы уже к обеду. И когда у тебя есть такая возможность, у тебя появляются еще идеи.
В больших компаниях, программные продукты должны пройти несколько одобрений прежде их запустят.
И это, действительно, так. По крайней мере, те стартапы (вебервисы/вебприложения), где мне посчастливилось работать, соответсвовали этому. Можно релизить на прод так часто, как только ты этого хочешь. Потому что минимальна стоимость как самих фич, так и по сути, стоимость возможных краткосрочных фейлов на проде (на начальном этапе). Что, естественно, невозможно в случае более крупной и стабильной кампании с регламентированным процессом разработки, планирования и поставки.
Проблема в том, что люди, которые предлагают ввести новые проверки, почти никогда не задумываются об их стоимости.
Каждая проверка имеет свою стоимость.
В статье мне очень понравились эти два предложения. Простая, очевидная и замечательная мысль.
Real artists ship — настоящие художники доставляют.
Дословный перевод тоже не плохой, пусть и теряет смысл про сроки)
Дословный перевод тоже не плохой, пусть и теряет смысл про сроки)
Вроде бы всё правильно написано. Но в этом нет никакой новизны. Просто красиво расписан банальнейший принцип, на котором строится любой бизнес: прибыль берётся из риска. Чем больше рисков компания на себя берёт, тем выше может быть её прибыль в случае успеха. Понятно, что проверки снижают прибыльность множеством способов. Но они же снижают и риски. И не существует способа снизить риски, не снизив при этом прибыльность. Во всём виновата проклятая конкуренция. Если гипотетически предположить, что существует магический способ снизить какой-то риск без дорогостоящей проверки, то тогда и конкуренты будут успешно его применять, и конкуренция вынудит снизить цену. Прибыльность всё равно уменьшится. Пусть не из-за проверок, повышающих себестоимость, а из-за снижения отпускной цены в условиях конкуренции. Проблема больших компаний состоит в том, что они не могут позволить себе большие риски. У них жестко задан потолок риска, который в принципе может считаться приемлемым. Но и никто не ждёт от них высоких прибылей. Пусть прибыль будет всего 4% годовых. Но зато это 4% от 10 миллиардов. А у стартапа прибыль может составить 300%, но от вложения объёмом всего в 100 тыс. Понятно, что когда у тебя есть всего 100 тыс., ты вынужден брать на себя любые риски, чтобы иметь возможность надеяться на эти 300%. Но если у тебя есть 10 миллиардов, то тебе проще вложить их в компанию, которая гарантированно будет приносить 4% в год.
В статье проводится две линии:
«закупки» и «поставка нового кода/функций в уже существующий продукт».
Про закупки
В нашей российской реальности, если людей, которые закупают не контролировать, они от безнадзорности скатываются в откаты и в карманные фирмы. И чем больше компания, государственная или коммерческая, тем с большей вероятностью это произойдет.
Про поставку новых функций
Для меня вопрос доверять или не доверять разработчикам это вопрос используемых ими технологий и метрик.
Если уровень профессионализма высокий, количество дефектов выявляемых Клиентами равно 0 или близко к этому, количество ошибок выявляемых при тестировании минимально, то в этом случае я склонен сокращать количество проверок на выходе при доставке функционала клиенту.
Второй момент, который тут необходим это качество выполненной постановки Бизнес-аналитиком, если функционал проработан с пониманием бизнес-задачи/проблемы клиента и производимые решения практически на 100% попадают в ожидания клиентов, то я также склонен уменьшать количество выходных проверок.
Если процент попадания далек от 100%, то ещё не факт, что то что сделано/разработано должно появится на продуктиве, можно считать это созданным рабочим прототипом, с которым нужно дать поработать Пользователю-Клиенту на тестовом стенде, чтобы он уточнил своё представления и требования к ИТ-решению.
И третий момент уровень контроля должен быть соразмерен масштабу бизнеса. Представьте что через вашу систему проходит транзакций в день на 1-2 млрд.рублей, в ней работает несколько тысяч партнеров компании, компания имеет 0,5% с этого объема, представьте что вы кладете систему очередным обновлением на 1-2 дня…
Это про управление рисками.
«закупки» и «поставка нового кода/функций в уже существующий продукт».
Про закупки
В нашей российской реальности, если людей, которые закупают не контролировать, они от безнадзорности скатываются в откаты и в карманные фирмы. И чем больше компания, государственная или коммерческая, тем с большей вероятностью это произойдет.
Про поставку новых функций
Для меня вопрос доверять или не доверять разработчикам это вопрос используемых ими технологий и метрик.
Если уровень профессионализма высокий, количество дефектов выявляемых Клиентами равно 0 или близко к этому, количество ошибок выявляемых при тестировании минимально, то в этом случае я склонен сокращать количество проверок на выходе при доставке функционала клиенту.
Второй момент, который тут необходим это качество выполненной постановки Бизнес-аналитиком, если функционал проработан с пониманием бизнес-задачи/проблемы клиента и производимые решения практически на 100% попадают в ожидания клиентов, то я также склонен уменьшать количество выходных проверок.
Если процент попадания далек от 100%, то ещё не факт, что то что сделано/разработано должно появится на продуктиве, можно считать это созданным рабочим прототипом, с которым нужно дать поработать Пользователю-Клиенту на тестовом стенде, чтобы он уточнил своё представления и требования к ИТ-решению.
И третий момент уровень контроля должен быть соразмерен масштабу бизнеса. Представьте что через вашу систему проходит транзакций в день на 1-2 млрд.рублей, в ней работает несколько тысяч партнеров компании, компания имеет 0,5% с этого объема, представьте что вы кладете систему очередным обновлением на 1-2 дня…
Это про управление рисками.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пол Грэм: Иная сторона «шедевров в срок»