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