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

Сложность арабского в том, что он оказался "ничейный". Все языки у нас идентифицируются по стандартной схеме ll-CC (язык-страна, en-US к примеру), еще со времен перевода на "бразильский португальский". Чаще всего мы поддерживаем только один региональный вариант (например у нас нет "британского английского", только "американский"), но тем не менее эти региональные варианты существенно отличаются мы не должны вводить в заблуждение.

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

После ожесточенных споров в духе сунниты против шиитов, пришлось исключительно для арабского вернуть идентификацию по языку без страны обратно ("ar").

HR-минутка. Кто уехал за границу не с компанией, а самостоятельно - тому может понадобиться новая работа, не все компании терпят удаленку за границей как по внутренним причинам, так и в силу мутности российского закона в этой области (есть интерпретация, что это вообще не разрешается - хотя я с ней не согласен).

В ходе недавнего обсужения сформулировали несколько советов со стороны компании:
1) спрос точно есть. в уехавших компаниях уехали не все сотрудники. это создает дыры от 10% до 50% персонала, которые им надо замещать. найм идет, спрос есть, без работы не останешься
2) если обращаться в уехавшие российские компании, или в компании с господством русскоговорящих (более верное слово, поскольку вовсе не все из России) в их ИТ, то слабый английский резко становится намного меньшей проблемой - это теперь проблема быта, а не работы. Опять же эти компании привычны к иммиграционным вопросам. Это кратно проще, чем пробиваться в старую добрую исконно-иностранную компанию.
3) часть уехавших крупных компаний (примерно половина проверенной мной выборки) не публикуют вакансии в hh.ru и России вообще. Но это не значит, что вакансий нет. Полистайте чатики, попросите вам в личку написать - какие конторы уехали (не все об этом громко говорят), где найм идет. Посмотрите корп.сайты известных вам контор.
4) рекрутеры землю роют, их много, они носят кандидатов компаниям - обойти их всех вы устанете, но попадите им на радар, заведите себе хороший профиль в HH и Linkedin. К каким-то 5-10 известным рекрутерам сами сходите. Вот newhr завели ботика к примеру https://yangx.top/newhrglobalbot

Мы сами все еще ищем
- руководителя devops команды. коммуникатор, организатор, горящие глаза, меломан инфраструктурно-облачных вопросов, девелоперский опыт обязательно. чтобы все четенько и с огоньком.
- linux инженера. чтобы на уровне всяких системных сервисов собирать, патчить, интегрировать, конфигурировать, писать обвязки на go/c++/ python/shell (по обстоятельствам). это все код, не админство. в ядро лазить не придется

Если кого такого знаете - пишите в личку (есть в описании канала), дам контакты.

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

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

Возьмем пример, что компания занималась онлайн бронированиями отелей и разработала внутри мощный софт для бухгалтерии. Все ресурсы компании настроены на продвижение на конкретном B2C рынке (бронирования). Есть навыки, есть специалисты. Теперь кто-то хочет инициативно предложить софт для бухгалтерии (B2B) - это другая область, это другие методы продвижения продукта. У компании нет готовых навыков и специалистов.

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

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

На этом месте где-то вдалеке засмеялся Морейнис и все остальные инвесторы и около-инвесторы, для кого аксиома, что продукт начинается не с решения, а с покупателя. Кстати, если вы не читаете человека по фамилии Морейнис и как-то работает над созданием продуктов - то моя личная рекомендация на него подписаться.

Соответсвенно в данном примере начинать надо с обращения к нескольким знакомым вашей бухгалтерии (тоже бухгалтерам) и поиску среди них первых пользователей. Если таковые найдутся, то шанс прорваться через барьер незнания, где ловить покупателей, станут раз в 10 выше.

Периодически сталкиваюсь с отношением, что "некогда тратить время на отчеты и прогнозы, делать надо".

Делать это очень хорошо. Однако, представьте, что вы наняли себе отделочников на ремонт квартиры. Ну или еще что-то - в моем случае плотники беседку делали. Вот они месяц трудятся, два трудятся. Но не могут сказать, сколько им еще нужно материалов, не могут сказать, когда закончат. Вы не можете понять, как вы следующие этапы планировать - к когда мебель привозить, к когда самим въезжать. Важно ли в конце, что они закончили работу на неделю раньше, чем если бы потратили какое-то время на планирование? На неделю раньше чего? У вас же в голове никакой даты не было. Единственная дата в вашей системе отчета, это когда вы начали спрашивать о времени окончания работ. Ваши рабочие в этой системе восприятия вообще не имеют шанса закончить раньше, они только опаздывают от даты, когда вы первый раз спросили.

Можно приводить еще кучу примеров - с поездками на такси, и т.п. Их всех объединит один простой принцип - в восприятии заказчика "скорость не важна, если нет предсказуемости". Опережать имеет смысл только ранее выданное предсказание, а без него можно только безнадежно опаздывать от ожиданий заказчика.

Зацепились языками на конференции про мерч/лут/раздаточные сувениры. Мой собеседник их никогда не берет, поскольку не хочет умножать количество мусора на планете. Я тоже не люблю мусор, но практический вывод в отношении мерча у меня немного другой.

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

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

В последние несколько лет кандидатам стало не нравиться делать тестовые задания. Они требуют много времени, подаются люди сразу в пачку компаний - понятно, что ТЗ обременяет. Рабочая альтернатива ТЗ это лайв-кодинг. Фиксированный слот времени, типовые задания делаются под присмотром сотрудника.

Плюсы лайв-кодинга очевидны:
+ (для кандидата) меньше времени вложено
+ (для компании) кандидат как на ладони виден, все в реальном времени.

Есть и минусы лайв-кодинга:
- (для компании) в несколько раз больше времени на наблюдение и оценку. ТЗ можно и за 15-30 минут проверять, а тут минимум час сидеть и следить.
- (для кандидата) все в живую, часики бегут. Нельзя досмотреть, дочитать, догуглить как это было с ТЗ - это наименее очевидный пункт имхо

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

При этом у меня есть гипотеза, что переход на лайв-кодинг наименее выгоден для тех, кто больше всех был недоволен затратами времени на ТЗ. Обычно ТЗ задумывалось таким, чтобы его можно было сделать за вечер. Это несколько больше чем 1-2 часа лайв-кодинга, но имхо не принципиально больше, чтобы быть решающим. Однако, если кандидату надо было что-то изучать для выполнения ТЗ, то это уже требовало нескольких вечеров. Затраты значительные и возмущение понятно, НО проскочить лайв-кодинг такому человеку становится наоборот труднее.

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

Поскольку это только гипотеза, то интересно услышать подтверждения-опровержения из вашего опыта в комментариях

Помните веселую картинку про оргчарты разных компаний, где майкрософт во все стороны ощетинился пистолетами (ниже)?

Она иллюстрирует проблему кучи организаций, где на границе отделов возникает "мы против они". Неплохим решением является ликвидация границ и слияние в одну команду. На моей памяти это и правда в корне решало болезненные противостояния. Правда с этим методом есть один нюанс - "всякая проблема решается добавлением слоя абстракции, кроме проблемы слишком большого числа слоев абстракции" - слить прямо вот все-все-все не выйдет (ну или выйдет неприкольно). Где-то будут границы. Сольем все функции в команду полного цикла? Тогда будут границы между несколькими командами. Упс.

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

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

Например, на заре своей работы я попал в компанию, где с духом кооперации все было не ахти, команда на команду и лидер на лидера волком смотрят, каких-то людей для кросс-командной координации не выделено, НО весь софт магически работал совместимо друг с другом БЕЗ особого администрирования над командами. Был простой институт в виде рассылки "я выпускаюсь и ручаюсь, что совместимость сохранил" + принцип "кто сломал, тот лох". Все. Два простых принципа и на нем сотрудничество работало много лет без какой-либо любви к сотрудничеству.

Вобщем, не стоит забывать про этот второй пласт инструментов. Орг.диаграмма, как ее не рисуй, все таки разделяет. А институты коммуникации объединяют.

Картинка про майкрософт, если кто не видел

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

Примером было, что в 1980 году McKinsey обосновали компании AT&T, что рынок мобильной связи в США не превысит 900 тыс человек к 2000 году, поскольку мобильные тогда были громоздкими, неудобными и страшно дорогими. В реальности, уже к 1992 году мобильных в США было 12 млн и это число быстро росло (в 1994 уже 24 млн), а вес телефона снизился до “всего” 250г. К 2000му году число мобильных пользователей достигло 109 млн. Ошибка стоила AT&T 12.6 млрд долларов на покупку мобильного оператора, чтобы догнать.

Следующим примером было, что также глупо было бы оценить рынок авто по количеству лошадей. А вот здесь уже не работает - в США в 1910 году (доавтомобильная эра) было 25 млн лошадей. А в 1950 году (автомобильная эра) было … 25 млн автомобилей. Ну потому что автомобили первым делом заняли собственно ровно ту нишу, которую прежде занимали лошади.

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

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

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

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

ПРИМИТИВНЫЕ РЕЦЕПТЫ

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

Возникает это, если команды “исполнитель” и “заказчик” из разных организаций (не образуют одной большЕй команды) плюс “исполнитель” делает кроме этого проекта еще и какую-то обычную работу или даже много других работ.

Искажение возникает от того, что свои собственные задачи “заказчик” видит как “длящиеся”, то есть занимающие время и ресурс. А вот такие проблемы на стороне “заказчик” воспринимает как “точечные” - я багу завел, а они пусть быстренько исправят. Не возникает понимания, что при этом тоже тратится какой-то ограниченный ресурс, и что дробь задача/ресурс образует какое-то существенное время.

Этому более подвержены ситуации, которые кажутся “заказчику” как баги (отклонения от ожиданий). И менее подвержены задачи, когда “заказчик” явно хочет, чтобы на той стороне что-то очень сильно переделали.

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

Другое решение это, конечно же, просто явная передача человека "заказчику" на время , но это не всегда приемлемо.

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

Как показало гугление - "все уже украдено до нас" и Dilbert Index придумали 12 лет назад. Впрочем, судя по малому числу упоминаний - это изобретение осталось незамеченным.

Если бы сайт dilbert.com оставался жив, то могли бы сделать рейтинг по компаниям, продавать им аналитику, написать своих ботов для мессенджеров, чтобы считать репосты. Распространяемая картинка автоматически бы идентифицировала собой беспокояющую тему. Но это все в какой-то альтернативной реальности.

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

Эксперименты показали, что
- 80% автоперевода сейчас уже ок и не требуют коррекции. Но 20% это довольно много и соответственно люди все еще нужны - читать надо все 100% текста + 20% править. В итоге расходы, конечно, меньше, но совсем не в пять раз, а примерно на треть.
- чем меньше контекст, тем хуже результат. лучше всего переводится документация (длинный связный текст), хуже всего короткие подписи в интерфейсе. ну или пока не придумали, как AI должен понимать смысл кнопок прямо из интерфейса (их и человеческие то переводчики не так легко понимали, часто лажали и для этого есть отдельные приседания)
- чем более редкий язык, тем стремительно хуже результат. Первые пять языков по распространенности отлично. Вторые десять норм. Дальше все быстрее идет в разнос.

И здесь появляется несколько неожиданных эффектов
- Если раньше за более редкими языками стояла просто меньшая выручка, то теперь и меньшая выручка и бОльшая себестоимость, поскольку они хуже поддаются оптимизации через автоматические переводы. Неравенство выросло.
- Эффект экономии от лучших результатов в топовых языках сильно снижается за счет усреднения от длинного хвоста более редких языков.
- Масштабировать _количество_ языков через AI можно советовать только тем, у кого переводов раньше не было. До 5 языков отлично. До 15 с трудом. Потом печаль. Мы уже не можем так расширять покрытие.
- Самый большой объем это тексты в интерфейсе, но они намного хуже поддаются автопереводу

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

По моим наблюдениям основатели небольших компаний при их поглощении "стратегом" (бОльшим бизнесом) не часто приживаются. Сужу как по знакомым, так и по статьям от поглощенных в гугл, мс и тп, так и по нашей конторе. Детальных примеров в памяти уже довольно много, так что можно что-то субъективно обобщить:

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

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

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

- Если основатель хотел бы просто забрать деньги и уйти, то тоже обычно нет. Сделка часто структурирована так, что живых денег дают не так уж много (это публика читает в новостях и завидует). Что-то будет акции новой компании (а она может не торгуется публично), что-то будет передаваться по календарю в течении следующих лет, в зависимости от успехов продукта, в зависимости от личного поведения. Человек оказывается в тисках - делать, что хочешь нельзя, бросить нельщя, уйти нельзя. Печаль.

Понятно, что описанное не повсеместно, но на каждого успешно интегрировашегося основателя я знаю наверное ~9 историй как выше.

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

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

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

- баловство для отдельных гиков в инженерке, инженерное руководство косится с подозрением
...
- разработка наглухо подсела на слак, инженерное руководство придумывает правила пользования/модерации, соседнии отделы игнорируют и морщатся, периодически грозятся прикрыть (но это уже нереально)
...
- вся компания сидит в слак, попытки его грохнуть забыты, но по серьезным вопросам "продублируйте в почту"
...
- пожилые очень бизнесовые дядечки говорят, что хватить уже пожалуйста мусорить в почте, давайте пожалуйста все в слак - нам так удобнее. Серьезная веха.

Конечно, слаку непросто выдерживать давление со стороны "халявного" MS Teams (включен в пакет МС услуг все равно)

К вопросу о возвращении в офисы - в этой карикатуре есть большая доля правды.

Если когда-то в офисе наступало время созвона и народ бежал дружно в один конференц рум, то потом даже в офисе народ при приближении созвона также дружно бежал уже в РАЗНЫЕ комнаты. Потому что так удобнее, не нужен гемор с подключением общего микрофона и т.п.

В региональных офисах ИТ гигантов два человека за соседними столами часто работали в разных проектах и командах и обсуждать им друг с другом было нечего.

В офисах вместо больших конференц комнат понадобились много маленьких, на одного человека, чтобы он мог говорить, не мешая остальным.

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

Наверное уже все слышали, про шумное исследование, что 10% инженеров в компаниях (смотрели на выборку в 50 тыс человек) не делают практически ничего.

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

Но к сожалению, статья (первоисточник) не отвечает достаточно детально про методику сбора данных. А то на моей памяти был случай, что установили моим бывшим коллегам софтинку, которая считала их продуктивность с оплатой по часам. И этот софт за продуктивность считал кодинг, а вот например сидение в терминале за настройкой и отладкой инфраструктуры он продуктивным делом не считал, к некоторой печали инженеров. Вот такой был "налог" на инфраструктурные задачи - но вроде оно там достаточно равномерно распределялось по людям, чтобы никого не задевать смертельно.

А так-то хотя мериться сотнями строк код это дурная практика, но посмотреть на объем созданного кода и подумать про отдельных выдающихся личностей полезно. Для этого даже AI был не нужен. С кем-то приходилось и прощаться после пары разговоров, но это 1%, а не 10%.

https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing

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

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

https://www.snopes.com/fact-check/yes-madam-fired-employees-stress/

Помните смешной текст про то, что все животные делятся на
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...
?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.

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

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

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

Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.

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

Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.

Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку

Смотрел, что недавно в confluence выкатили функции встроенных баз данных - очень прикольная штука, но оказалось, что к ним еще не был готов бекап/рестор, что для более-менее крупной организации, конечно стопор для активного использования. Это заставило задуматься еще раз про в каких местах правильно срезать углы, если надо выкатить продукт пораньше.

Как удачный пример припоминаю решение выкатить продажу SSL сертификатов в магазине без возможности их продления (выписывались на год) со словами "их продление еще год никому не понадобится". И угол срезали и никто вообще ни в чем не ограничен на практике.

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