Pull to refresh

Comments 277

Ну тут или одебиливание или мясорубочка. А хуже всего динамичные компании. Они и то и то.
Хуже динамичных только «динамично развивающиеся».
С молодым и дружным коллективом. Но в вакансии потребуем стрессоустойчивость.
Обычно «дружный коллектив» подразумевает «мы тут дружим, а ты чужой хер, мы тебя не звали», поэтому и стрессоустойчивость.
Волки загнали собаку, окружили, хотят сожрать. Собака просит не убивать её, взамен обещает помогать загонять овец и пр.
Волки подумали и оставили собаку в стае. Два года она им помогала, всему учила, показывала места, охотилась вместе с ними…
Настала особенно голодная зима, охоты неудачные, волки голодные, отчаявшиеся. Что делать? Решили всё-таки сожрать собаку. Сожрали. Косточки похоронили. Поставили надгробие. Думают, как подписать, от кого? «От друзей»? Так вроде какие какие друзья, раз сожрали… «От врагов»? Так 2 года вместе бок о бок жили, охотились, никто в обиде не был… Подумали и написали «От коллег».
Еще возможен вариант, когда в начале наоборот все очень круто и дружелюбно, но если через время бывший новичок будет показывать лучшие результаты со всеми вытекающими… вот тут и понадобиться стрессоустойчивость.
Хотя как это можно проверить при приеме на работу для меня загадка. Наверное можно, но почти нигде не проверяют.

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

Осталось только понять почему Андроид от компании, в которой действительно написали систему сборки (и не одну), систему версионирования исходников (тоже не одну) и состряпали распределённых кешей (в количестве) стоит на миллиардах устройств, а операционки от компаний «этим не страдающих» — всё загнулись…
Потому что эта компания купила Android, Inc за 130 млн долларов и надо было всего лишь не угробить? Задачу «не угробить» облегчили себе тем, что выложили Андроид в исходниках под лицензией которая допускает правку всеми? (Play Services появились уже потом да и существовать без Play Services в принципе можно — с кучей проблем но можно — живет ж Амазон)
Ну купили они не операционку, а команду. Никакой операционки на момент продажи у них не было. Были кой-какие демки, ещё даже не было решено на каком языке «всё вот это» писать… По вашей логике получается, что «одебилевшая компания» — это примерно такая, которая может взять дворовую хоккейную команду, чемпионов Жмеринки и сделать их чемпионами мира… а тогда точно ли к такому применим эпитет «одебилевшая»?

Не очень понятно почему такого состояния нужно бояться и с ним бороться…

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

А, спасибо, что напомнили. Считать себя гуглом и копировать их паттерны тоже один из признаков.


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

А оценка даже снизу вашего интеллекта позволяет заключить, что вы вполне в состоянии найти, почему ваш тезис не подходит как контр-аргумент.
Вы меня переоцениваете. Всякие собственные системы сборки и кеши в Гугле были ещё когда там человек 500 работало… Так почему Гуглу можно, а вам — нельзя? Где грань?

Нет, понятно, что если в компании работает человек пять, а она мнит себя Гуглом и разрабатывает систему, которая будет управлять миллионом компьютеров… Тут что-то явно не так… Но если в кампании 100 человек? Или 1000? С какого момента это становится нормальным?

Потому что гугл делал систему сборки 20 лет назад, когда с системами сборки в мире C++ всё было очень плохо.


Если вы сегодня будете делать систему сборки, то вас обгонит компания, которая не тратит на это время.


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

Знавал компанию, в которой написали собственный логгер, хотя можно было обойтись стандартным. И еще пару мелочей в таком же духе.

Так и не стали Андроидом :).
написали систему сборки (и не одну), систему версионирования исходников (тоже не одну) и состряпали распределённых кешей (в количестве) стоит на миллиардах устройств, а операционки от компаний


Почему Вы думаете, что это связано? Операционки от MS и Apple тоже стоят в миллиарде устройств, но в качестве системы контроля версий там сейчас, насколько мне известно, пользуются гитом. Хотя обе эти компании в свое время страдали NIH синдромом более, чем широко. Кстати, в качестве основных языков для разработки под Android выбрали сначала чужую Java, а затем чужой Kotlin.
Перевод конечно вольный — я бы сказал, не просто вольный, а прям какая то адаптация сериала.
Оригинал
8. 8:00 am – 10:00 am–Japanese cars exceed German cars

Перевод
8. 8.00 — 10.00 — нищебродских корейских иномарок больше чем пафосных немецких тачек..

Оригинал
8. Someone whose music sells in the iTunes music store performs at the company Christmas party.

Перевод
8. Земфира поет на вашем новогоднем корпоративе.


нищебродских корейских иномарок

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

Это всё равно на голову лучше типичного «перевода», из которого гроздьями торчат непричёсанные английские грамматические конструкции.

нищебродских корейских иномарок

В русском переводе «Американцев» тоже упоминается «корейский драндулет». Ну и если бы автор сохранил «японские машины», то перевод получился бы хоть и точный, но менее понятный – у нас в стране японские и немецкие машины примерно равны по статусу.

И с Земфирой тоже метко: мало ли кто там что где продаёт, это у нас абсолютно не показатель. А Земфиру все знают)
в оригинале герой Алика Болдуина на самом деле про конкретную корейскую марку автомобиля говорит, которая сейчас очень распространена у нас и её название начинается, пардон, с буквы «Х» (ссылка на фрагмент в первоисточнике). А то, что перевод обобщили и всех «корейцев» подстригли — так это, возможно, по соображениям этики (ну или ещё чего).
Наверное, из-за того что я не был в Японии, мне представляется с трудом, что для среднестатистического японца в его технологически развитой Японии другой среднестатистический японец, обладающий японским автомобилем ассоциируется как нищеброд.
Пс. просто вообще не люблю это слово, которое очень любят применять те, у кого вот только что появилось 5 золотых в кармане, и теперь все, у кого в кармане меньше, для них нищеброды.
по-моему, замечательная адаптация
Читал, не заметив плашку перевод, и до этого комментария не знал, что не оригинал, так что, прекрасная работа.

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

А еще их мнение учитывается начальством наравне с программистским при решении, например, чисто технических вопросов.

А еще их мнение учитывается начальством наравне с программистским при решении, например, чисто технических вопросов.
Даже больше — в основном их мнение учитывается при решении специфических вопросов (имеющих опеределённую специфику: технические, экономические, ...)

Есть отличный совет — проводить совещания стоя. Сокращает время, проведённое на них, в разы.

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


Выглядело это очень смешно.

А, да, там ещё перед тем, как стать тимлидом, нужно было прослушать курс с названием «Path to leadership».

На второй картинке лошадь, которая работала больше всех, но так и не стала председателем.

Мечта всех эффективных менеджеров — нанять рабов на галеры. И так будет всегда пока есть эффективные

А что на счёт бюрократии? За каждую мелочь все посылают писать заявку в соответствующей системе или эмайл с получением кучей не нужных "ок"-ов

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

А это кому инструкция? Руководству? пфффф…
В чём суть претензии? На старте компании руководство хотело денег и купаться в пафосе. Вы сосредоточенно и с полной отдаче работали, и теперь у них всё это есть, и они этим наслаждаются. Mission accomplished!
>Настаивайте чтобы менеджеры нанимали лучших менеджеров чем они сами:
>Например тимлид должен нанять программиста, лучшего чем она, уж точно не хуже.

Взяли вот так с ходу и смешали менеджеров и программистов в одну кучу.

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

А главное — кто это «лучше чем» будет оценивать?
Ну вообще наверное да, с любыми. Ну и потом, как ниже резонно написали, кто их будет оплачивать, самых лучших? Я уже не говорю о том, чем вообще их заманивать.
Тут вопрос — что вам нужно, специалист как и техника должен быть достаточен для решения вашей задачи. Если менеджмент не знает кто им нужен это проблема в любом случае
По-моему, описанное в статье типично для компании, где ИТ не является приоритетным. Ну а то, что начальство ездит по международным командировкам, а сотрудники пашут 8-часовой рабочий день — это нормально, just business. Только новичок может завидовать тому, что у начальства или менеджмента машины лучше, особенно если этот новичок никогда не пробовал открыть никакого дела сам.

Но если на корпоративе компании поет Земфира, а сотрудники не могут 100$ на новый SSD-диск у руководства выбить (лично видел как некоторые покупали себе в офис стул или монитор получше за свой счет в довольно крупной компании), то да, это звоночек что возможно есть места и получше :)

С другой стороны, главная добродетель начальства — не мешать работе. Так что пусть что угодно на корпоративах делают, если задачи интересные и зарплата платится вовремя, то и бог с ними.
И обычно у начальства или менеджмента машины и квартиры явно не соответствуют зарплатам
Командировки тоже бывают разные. С точки зрения «сотрудников» — «а, вы там наверное по пляжам шлялись и стейки хомячили». С точки зрения CEO и CTO — «весь полет вносили правки в презентацию, ночью фигачили почти 400 км на машине. Потенциальные клиенты — тоже не дураки, стараются минимизировать свои обязательства и максимизировать наши. Потом еще встреча — в другом городе. А оттуда нужно еще вернуться, сдать машину и первый раз за трое суток нормально (сидя) пожрать».
Согласен.

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

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

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


Т.е. мидлы компании совсем не нужны и джуны, одни сеньоры? А если нанимать программиста круче чем лид, то ведь и денег надо ему больше платить. Как-то это совсем странно выглядит.

А кто будет выполнять тупые задачи типа формирование очередного отчета для бухгалтерии или интеграция со 100500м API? Сеньоры это могут делать, но это слишком скучно и будет их демотивировать (или мотивировать свалить отсюда подальше), а джунам это в радость.
Смотря какую задачу в данной компании выполняет тимлид. Если тимлид = ведущий разработчик, тогда да, Ваш комментарий релевантен. Но есть компании, где тимлид — менеджерская позиция, где у тимлида 5-7 разрабов в подчинении и его обязанности: дейли провести, таски в спринт накидать, плэннинг провести, с продактом задачки обсудить, на митинги с руководством ходить и в принципе заниматься управлением. И дай бог останется у такого тимлида 2-3 часа в неделю на кодинг. И вот в этом случае найм разработчика выше уровнем, чем сам тимлид — вполне себе нормальная практика. Да и потом не каждый синьор горит заниматься менеджерской работой, так что тут никаких противоречий.
Хм, если человек не занимается кодингом, то я бы не называл эту позицию тимлидом, просто менеджером. Хотя верю, что в разных компаниях своя терминология. А менеджеру не обязательны технические скилы, он может вовсе не уметь программировать. Тогда любой программист будет лучше чем он, даже самый посредственный. Т.е. сравнивать гуманитария менеджера с программистом вообще непонятно как.

Тимлиды обычно почти не кодят. Не больше половины от общего времени уж точно.

Я может быть ошибаюсь, но всегда считал, что "хороший" и "опытный" это понятия, конечно, кореллирующие, но не синонимы. Может быть хороший тимлид и плохой тимлид, так же может быть хороший толковый джун, который когда-то вырастет в мидла или дальше, и плохой джун… И это в общем то относится, наверное, к любой профессии.
Думаю имелось ввиду, что надо нанимать хороших джунов, хороших мидлов и т.п. а не то, что надо брать одних тимлидов…

Объясните пожалуйста, почему каждая вторая компания высасывает из пальца какую-то «миссию»? Для чего нужны эти пафосные и лицемерные фразы?
ИМХО, единственная настоящая миссия у коммерческой компании только одна — заработать денег. Всё. Только для этого она и создавалась — вне зависимости от того, осознавалось это владельцами, или нет.
они боятся формулировать, надо зашифровать. вместо декларации «мы хотим заработать денег»

Деньги можно тоже по разному зарабатывать. И одно дело если вы например помогаете людям решать проблемы и зарабатываете на этом деньги. И совсем другое дело если зарабатываете деньги тем что создаёте людям проблемы.


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

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

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

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


Но к счастью несмотря на всё это, в мире полно и хороших честных врачей и хороших честных инженеров :)

И пусть и тех и других будет больше!
Изначальный посыл видимо сводится к тому, что в случае всеобщего благополучия- врачу и полицейскому придётся менять профессию, а инженеру не придётся. Только как-то криво получилось, аморально. По другому бы выразить.
Лично знаю очень хороших врачей, профессионалов своего дела, любящих свою работу, которые с радостью сменили бы свою профессию в обмен на общее здоровье. Ещё и расценили бы это как новый опыт. В мире так много интересного. Всегда найдёшь, чему учиться и к чему приложить свои силы.
А пока -да, пусть будет больше хороших честных врачей, учителей и инженеров.
Можно сказать, что инженер надеется что ваш дом развалится чтобы построить новый
Скорее так — инженер строит дом из специально разработанных материалов, перестающих служить на следующий день после окончания гарантийного срока.

Во-первых, есть чисто благотворительные компании. Во-вторых, деньги — это инструмент, а в условиях капиталистической экономики — необходимый. А что делать, если денег достаточно и даже много? Как минимум расширять влияние, штат, инвестировать в более рисовые проекты. Так что нет, не все, не для этого она создавалась, если это конечно не чистый отмыв.

Много программистов, которые открывают код просто так, не думая о монетизации (ну ок, о репутации, карьере может и думают). Скорее всего такие люди существуют не только среди программистов, но и бизнесменов.

Владельцы очень редко создают компанию только для заработка денег — 90% компаний просто прогорают не выйдя в плюс.

Хотя как раз слово «миссия» это из мира корпоративного буллшита, конечно, если речь идет не про НКО
Миссии, по их задумке это стимул, ведь согласитесь, что прямое знание того, что живешь и работаешь, что бы кто то другой жил все лучше и лучше используя плоды твоей работы, по определению не самый лучший стимул. Исключение лишь при полной прозрачности процессов,
когда каждый получает свою, за ранее оговоренную долю, пропорционально внесённому в общий процесс вкладу или типа того.
ведь согласитесь, что прямое знание того, что живешь и работаешь, что бы кто то другой жил все лучше и лучше используя плоды твоей работы, по определению не самый лучший стимул.

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

Ну тогда Ваша жизнь сплошное блаженство, не часто вижу, что бы кто то заказывал, а потом не использовал и в добавок абсолютно бы не интересовался, насколько быстро он сможет получить желаемое в лучшем виде, но все не так просто, гораздо правильнее ориентироваться на свое внутреннее состояние и здраво воспринимать адекватную критику, все остальное лишь манипуляции, слова людей обычно мало что значат, у каждого своя цель.
Хотя конечно выше, я малость погорячился в своём высказывании изначально миссия была задумана, как некий объединяющий фактор, который добавляет чуточку игры в рутину, но дело тонкое, чуть переборщил и вот всё уже превратилось в одну сплошную игру.
не часто вижу, что бы кто то заказывал, а потом не использовал и в добавок абсолютно бы не интересовался, насколько быстро он сможет получить желаемое в лучшем виде
Э нет. Не путайте «востребованность» и «кто-то пользуется твоим трудом» и «абсолютно бы не интересовался, насколько быстро он сможет получить желаемое в лучшем виде»

Огромное количество работ, исполняемых программистами — это разновидность армейского «хацю шоб слоники побегали».

То есть вымотать из программиста все нервы — это святое… А потом это поделие засунуть куда-нибудь и никак не использовать — это тоже сплошь и рядом.
Ну таких за километр обхожу, у них и бабла-то нету никогда, а то что фича устарела пока делали или придумали что-то по лучше, вполне нормальное явление,
главное что бы время было оплачено.
Пирамида Маслоу это разговоры в пользу бедных
Ничего себе — ещё и карму в минус загнали. Хорошо, что карма существует только на хабре а не в жизни. Это я в к тому что компании расплачиваются данными принципами вместо части зарплаты

Потому что когда люди работают за общую, объединяющую идею, им можно не платить за переработку.

Правильно говорите, смотрите чтобы вас как меня не слили

Да я уже привык. Причём самое забавное, что плюсы ставят пока комментарии свежие, а вот минусы могут потом ещё долго прилетать :)

Еще и карму в минус загнали — ну и ладно

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

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


Google: Цель компании Google – упорядочить всю информацию в мире и сделать ее доступной каждому


Amazon: Our vision is to be Earth's most customer centric company; to build a place where people can come to find and discover anything they might want to buy online.


...


Киоск с шаурмой: Мы накормим Южное Бутово самой дешевой шаурмой с картошкой


Разумеется, если вы еще не заметили, то люди из всего делают карго культ.

Да просто карго культ.

ИМХО, единственная настоящая миссия у коммерческой компании только одна — заработать денег.


Есть небольшое число компаний, для которых важно не просто заработать бабло, но и сделать продукт хорошего качества. Такие компании грубо говоря не будут пихать пальмовое масло в печенье. И не будут на упаковке йогурта писать 110 грамм, когда там на самом деле 90, включая упаковку. А чтобы рядовые сотрудники понимали, что компания тут не ради бабла, а ради хорошего продукта можно сделать хорошую и понятную миссию-слоган. Если это единственная мера, то этого естественно не достаточно.

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

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

Есть небольшое число компаний, для которых важно не просто заработать бабло,


Можно назвать несколько таких компаний?
Особенно из тех, которые это бабло уже заработали.
Не ручаюсь, но по тому что описано в книге, например Patagonia (производство одежды и снаряжения).
Ну и еще мне кажется социальное предпринимательство тоже в эту сторону. Люди в первую очередь хотят решить какую-то социальную проблему.

Потому что в современном мире мотивация сотрудников основана не только на деньгах. И наличие какой-либо дополнительной цели будет радостно воспринято частью персонала. Человек, знаете ли, ищет смысл в своём существовании.

Миссия — штука полезная. Только не все умеют ее готовить.
Миссия — это маяк, на который должны ориентироваться сотрудники при принятии решений. Вот как пример миссия Youtube:


To give everyone a voice and show them the world. We believe that everyone deserves to have a voice, and that the world is a better place when we listen, share and build community through our stories.

Это — хорошая миссия.
Например, поставьте себя на место менеджера Youtube несколько лет назад. Представьте, что у вас есть вопрос: добавлять ли возможность комментировать чужие видео? Вы прочил миссию, и поняли, что комментирование помогает "build community", то есть соответствует миссии.
Или, допустим, появился вопрос: добавлять ли возможность стриминга прямо с телефона? Ответ: да, это соответствует миссии "To give everyone a voice".


Повторюсь, к сожалению, у многих компаний совершенно невнятная или непонятная миссия. Я вот сам за 9 лет работы так и не понял сути миссии текущего работодателя...

Только ведь ютуб тот еще цензор, и этой миссии он нифига не соответствует.

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

Нет, случаев бана в США вещей, которые вполне в том же США попадают под protected speech, предостаточно, можно погуглить про то, как ютуб забанил очередных, как нынче модно говорить, носителей ультраправых взглядов.

Удивитесь, но у некоторых людей идеальная (от слова идея) мотивация может быть основной, стоящей над денежной.

В это совсем невозможно поверить, человеку не обладающего такой мотивацией.
Я думаю что все знаю таких людей, хотя бы теже учителя и врачи. Сомнения возникают на этапе того, что может ли такой человек стать предпринимателем и успешно управлять компанией в течении продолжительного времени, конкурируя с другими и не уронив при этом качество продукта.
Объясните пожалуйста, почему все считают что цель любой компании «заработать денег»? ИМХО это не совсем так. Почти у каждой компании есть некоторые задачи и чтобы её выполнять приходится зарабатывать деньги. Сам по себе этот доход не имеет какого либо смысла, почти всегда средства нужны для какой либо текущих целей, расширение сети, pr проект, открытие завода и т.д. Конечно это все вопрос уровня курицы и яйца, но все же вот такие категоричные заявления сильно искажают восприятие.

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

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

Вы извините, но цель большинства частных компаний это именно заработать деньги. Просто иногда это "заработать здесь и сейчас", иногда "зарабатывать не определённом отрезке времени", а "иногда зарабатывать в идеале бесконечное время".


А ваши "текущие цели" это всего лишь инструмент для того чтобы увеличить отрезок времени на котором будут зарабтываться деньги и/или в увеличить количество денег, которое будет зарабатываться в будущем.

По моему конечная цель любой компании — расширение и выживание.
Не совсем так.

Объясните пожалуйста, почему все считают что цель любой компании «заработать денег»?
Строго говоря цель любой компании — делать то, что скажут акционеры.

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

Есть и совсем особые случаи, скажем в случае Гугла 50% акций находятся у «триумвирата» (Брин, Ларри, Шмидт) и они втроём могут договориться и решить делать что-то, что всем остальным акционерам не нравится никак (маловероятно, впрочем: если даже один из них сойдёт с ума вряд ли двое других безоговорочно их поддержат).
Есть и совсем особые случаи, скажем в случае Гугла 50% акций находятся у «триумвирата» (Брин, Ларри, Шмидт) и они втроём могут договориться и решить делать что-то, что всем остальным акционерам не нравится никак (маловероятно, впрочем: если даже один из них сойдёт с ума вряд ли двое других безоговорочно их поддержат).
И на них подадут в суд за ущемление миноритариев, за что тем придётся компенсировать прочим потери, а может и выкупать акции, ага
Это вряд ли. Про то, что структура акций устроена вот именно так и про то, что миноритарии не смогут с этим ничего поделать — написано ажно в заявке на IPO, в SEC поданной.

И этот подход весьма распространён в разных медиа-компаниях (всякие New Your Times и Desney), так что вряд ли суды будут склонны менять статус-кво.
Да нет, суды принимают решения по факту ущемления прав миноритариев независимо от. То есть если они решат дивиденды из прибыли не платить, например, а всё в развитие кинуть — можно суд не выиграть. Или если действия глав привели к обвалу котировок и при этом можно будет заподозрить злой умысел. Так что могут то они могут, но не что угодно.
То есть если они решат дивиденды из прибыли не платить, например, а всё в развитие кинуть — можно суд не выиграть.
Google ещё ни разу не платил дивиденов. И не собирается. Где суды?
«мы хотим заработать денег» — это отражается в типе компании (коммерческая\не коммерческая).
Миссия компании — это своеобразное лекало, которое можно приложить к сомнительной ситуации и принять решение.

Ну например: есть оборудование, обладающее некоторыми, пусть выдающимися, характеристиками, но построенное на сырой технологии. Можно ли его продать?

И если вы торговая площадка, миссия которой «продать хоть черта лысого» — однозначно да.
Если вы производитель оборудования, который «делает надежное оборудование» — однозначно нет.
Потому что не имея цели непонятны перспективы. Понимает ли руководство, чего оно хочет? Есть ли будущее у компании? В каком мы положении сейчас? Все хорошо с компанией, мы растем, выходим на новые рынки? Если да, то я могу, например, взять кредит долгосрочный или еще что то… А если всего этого нет, мы все тут как белки в колесе и сегодня есть, а завтра нет, то зачем такое место? Миссия — это по сути ваша цель и она нужна, да и её нужно озвучивать, имхо
Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю

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

А с последним что не так?

По идее DevOps подразумевает под собой что "dev" и "ops" работают вместе в одной команде.

Вы смогли сказать мою мысль в 4 раза короче))) Сестра таланта)))

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

Потому, что DevOps — культура взаимной ответственности dev'ов и ops'ов, когда они сами разгребают свое дерьмо. Когда вы снимаете ответственность с dev'ов и ops'ов и перекладываете на какой-то третий отдел, то DevOps на этом заканчивается по определению. А вместо него начинается бесконечно разрастающаяся автоматизация костылей, что и есть тема сегодняшнего диалога — "одебиливание".
Вообще, ящетаю, отдел DevOps — это уже последняя стадия лицемерия.

UFO landed and left these words here
С компанией становится все понятно, когда в ней заводятся коучинг, менторинг, наставничество, миссии, тренинги по управлению эффективностью и т.п. Незаметно вдруг вы замечаете, что 30% времени ваши сотрудники тратят на чтение рассылок с новостями HR, просмотр презентаций о миссиях, корпоративной культуре, участвуют в каких-то конкурсах, номинациях, тестах и прочей лабуде. А на деле оказывается, что HR не способен банально не может подобрать вам кандидатов, потому, чти у них у самих текучка и все, что могут предложить — разместить вакансию на hh и насыпать вам откликов.
Что не так с менторингом? Когда более опытный сотрудник помогает менее опытным в решении учебных и рабочих целей это же хорошо.

Это естественный процесс. Не так — то, что из обычных казалось бы явлений, начинают делать культ.

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

Или что еще хуже — эффективный менеджер
>Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю
Компания практикует такие методики управления проектами, как аджайл и скрам. (аджайл является убийцей бизнеса хотя бы потому, что напрямую способствует росту технического долга)
Хуже, когда вешают доску и говорят: У нас теперь аджайл! В остальном при этом ничего не меняется, остаётся в лучшем случае водопад.

Ну так хорошо, если водопад остается. Вполне работающая методика.

Для ресурсоемких и наукоемких разработок как раз нужен водопад

Пожалуй что так, согласен. Собственно, везде, где есть стратегическое планирование, аджайл не подходит, он не для этого создавался.

Хорошо бы чтобы практики и методологии читали как инструкцию к лекарству — сначала показания к применению
Когда есть полные и (почти) неизменные техтребования и понятный протокол тестирования, то водопад или V-модель самое то. Но под новой вывеской придётся ещё торчать у доски, на ежедневных пятнадцатимитках, где говорит «за вчера я не закончил ни один модуль целиков», а если особо повезёт, то ещё играть в «покер планирования» с высокими ставками.
Просто гибкие методологии стали пихать куда попало, или просто этикетку переклеивать. Если делать что-то небольшое, на повремянке и без окончательного понимая заказчиком, а чего он, собственно, хочет — гибкие методологии самое то. MVP, короткие итерации, стейкхолдер/ПО прям в команде… А поскольку таких экспериментаторов несколько, то тут и «flexible commands» в тему: ну не нужен сейчас, например, дизайнер, ну он и ушёл.

Аджайл из веба пришел, пусть он туда и возвращается, там ему место.

Почему? Мобильная разработка и любая кастомизация тоже вполне подходят.

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


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

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


  1. Наличие собственно определенных принципов на которых строится методика отличных от других методик. Например в одной из методик говорится что главным является тесное взаимодействие между людьми участвующими в разработке. Где тут научная новизна?
  2. Наличие связи между принципами и собственно методиками чтобы можно было сказать что этот пункт методики соответствует какому тот принципу. Зачастую можно наблюдать что предлагаемые частные методики с натяжкой связаны с исходными принципами которые были озвучены в манифесте.
  3. Критерии по которым можно доказать что компания следует или не следует принципам и методикам.

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

У большинства "модных методик" описаны правила которым надо следовать. Обычно они описаны достаточно чётко. Как минимум в случае скрама это так.
Если этим правилам не следовать, то вы уже однозначно неправильно следуете методике или по хорошему вообще ей не следуете.


П.С. Ну и я на своём личном опыте уже успел почувствовать что происходит когда фирма переходит на скрам и следует правилам. И что происходит когда фирма просто говорит что переходит на скрам и при этом придумывает какие свои "с(к)рамоподобные" правила и процессы.

Ну и я на своём личном опыте уже успел почувствовать что происходит когда фирма переходит на скрам и следует правилам. И что происходит когда фирма просто говорит что переходит на скрам и при этом придумывает какие свои "с(к)рамоподобные" правила и процессы.

Не сочтите за труд, расскажите, интересно все-таки

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


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


Это если коротко и про техдолг.

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


Про backlog тоже интересное наблюдал: взял сотрудник (не я) задачу из бэклога, поковырял ее, поковырял, не получилось, и он обратно ее в бэклог запихал (он сам на митинге об этом рассказал). У меня от удивления глаза на лоб полезли: Гениального философа… Величайшего программиста современности… И запрячь в тяжеленную машину недоделанную задачу запихать обратно туда откуда взял?! Что за хрень?!?!


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


Список задач — это контракт между тобой, и твоим непосредственным начальником, что написано — то и делаю. Не написано — не делаю.

Похоже, вы решили обойти скрам и делать все по-человечески.

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


Если бы вы еще и от скрам-митингов отказались, а делали бы все согласно ТЗ, то это был бы не скрам, а водопад.

Мне интересно как вы пришли к такому выводу. На мой взгляд именно митинги не делают разницы между скрамом и водопадом. И как раз одна из распространённых ошибок это добавить в водопад скрам-митинги и считать что ты теперь делаешь скрам :)


Scrum означает толкучка, в которой весь коллектив решает что нужно сделать и когда. Т.е. нет стратегического планирования, нет четких сроков поставки продукта и т.д.

Это абсолютно не так. Команда решает как конкретно реализуется та или иная фича из бэклога. Какие фичи добавляются в бэклог и в каком порядке их делать, решают ПО и клиент в лице стэкхолдера.


"Стратегическое планирование" от этого не будет хуже чем в том же водопаде. Зато наоборот есть возможность относительно быстро среагировать если вдруг что-то пошло не так или клиент решит что он хочет идти в другом направлении.


Про backlog тоже интересное наблюдал: взял сотрудник (не я) задачу из бэклога, поковырял ее, поковырял, не получилось, и он обратно ее в бэклог запихал

Опять же это не скрам. Что берётся из бэклога на следующий спринт решает вся команда. И этим она обязуется сделать это до конца спринта. "Запихать" что-то обратно в бэклог можно только если спринт отменяется целиком и это очень редкое явление и я не припомню ни разу чтобы у нас это инициировала команда.


Она также плоха для разработчика — четкий список задачь с конкретным дэдлайном хоть и заставляет ответственно относится к работе и уметь оценивать своё время разработки, но он также и защищает от сверхэксплуатации со стороны работодателя

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


П.С. Вы извините конечно, но по тому что вы пишите я вижу что вы не особо то и понимаете что такое скрам и как он должен работать.

"Стратегическое планирование" от этого не будет хуже чем в том же водопаде. Зато наоборот есть возможность относительно быстро среагировать если вдруг что-то пошло не так или клиент решит что он хочет идти в другом направлении.

Вот! Я же говорю, что скрам слишком гибок — прогибается под клиента. Я это тоже уже проходил — компания, в которой я работал, тоже прогибалась под клиента, а тот постоянно менял ТЗ. Кончилось это вот чем: более миллиона у.е. долга для самой компании, реструктуризацией, и поглощением материнской компанией. Деньги потом все же выбили, через суд.

Вот! Я же говорю, что скрам слишком гибок — прогибается под клиента.

Что в вашем понимании означает "прогибается"? Это же не так что "изменения направления" делаются за счёт фирмы-исполнителя. Если нужны глобальные изменения, которые сильно отличаются от изначального ТЗ, то это всё обычно делается за дополнительные деньги.
Или грубо говоря есть бюджет и если есть изменения, то все они делаются пока бюджет не исчерпан.


Другое дело что для клиента это обычно всё равно выгоднее чем получить в результате "неправильный продукт" из-за неправильного ТЗ.

Что в вашем понимании означает "прогибается"? Это же не так что "изменения направления" делаются за счёт фирмы-исполнителя. Если нужны глобальные изменения, которые сильно отличаются от изначального ТЗ, то это всё обычно делается за дополнительные деньги. Или грубо говоря есть бюджет и если есть изменения, то все они делаются пока бюджет не исчерпан.

Это даже не разработка, это CAM — Computer Aided Masturbation. Но если подходить с тем, что цель — тянуть деньги из клиента, то почему бы и нет? Но я все же надеюсь, что ракеты наши (одна из немногих вещей, которые у нас остались после ликвидации СССР Горбачевым) никогда не будут разрабатываться по аджайл.


Другое дело что для клиента это обычно всё равно выгоднее чем получить в результате "неправильный продукт" из-за неправильного ТЗ.

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

Это даже не разработка, это CAM — Computer Aided Masturbation. Но если подходить с тем, что цель — тянуть деньги из клиента, то почему бы и нет?

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


Недовольны похоже только вы. Причём мне даже как-то странно и непонятно чем именно вы недовольны....


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

Во первых "правильное ТЗ" это на мой взгляд даже более редкое явление чем "правильный аджайл".


А во вторых некоторые проекты идут 3-5-10 лет. А наверняка и дольше бывают.
И у нас сейчас так быстро меняются обстоятельства что написать ТЗ на столько лет вперёд это практически невероятно.
Одни изменения законов чего стоят. Или изменения в трендах. Или появления новых технологий.
И этот список можно продолжать очень долго.

Что ж это за «стратегическое планирование», при котором нужно быстро менять направление?! Это показатель как раз того, что заказчик не делал стратегического планирования: не изучал рынок, не прикидывал стоимость и т.д. А потом «внезапно» оказалось что, то что было «киллер фичей» оказывается уже кто-то делал и она уже умерла пару лет назад.

Самое обычное планирование. Потому что если например планируешь на 3-5 лет вперёд, то абсолютно не всегда ясно как себя будут вести и что напридумают за это время конкуренты.
И тренды сейчас на 5 лет вперёд можно только ванговать. Да и изменения в законах пожалуй тоже.

Раз вы уже ответили — возвращаю коммент:
У аджила и скрама есть описание когда они помогут и когда они НЕ помогут, а помешают?
Если нет — их трудно воспринимать серьезно

Нет. Вот их принципы: https://agilemanifesto.org/principles.html, часть из которых просто ложные утверждения, например вот это: "The best architectures, requirements, and designs
emerge from self-organizing teams"

Нда, значит COBIT намного адекватнее (хотя и из другой оперы)

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


Установка была такая: техдолг разгребать сейчас не время, а надо быстро-быстро прилепить еще фичу, чтобы заказчик продолжил финансировать проект. Штука в том, что на разгребание техдолга НИКОГДА нет времени, а потом все либо падает, либо приходит в состояние, в котором дальнейшее развитие просто невозможно.


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


Один из краеугольных камней аджайла это "работающее ПО важнее исчерпывающей документации", т.е. присутствует прямая установка на создание техдолга. Техдолг смертелен для IT бизнеса. Значит, аджайл следует избегать at all cost, если хочешь выжить как компания.

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


А если у вас весь девтим решил наплевать на техдолг, то у вас не со скрамом проблемы, а с девтимом.


П.С. И "работающее ПО важнее исчерпывающей документации" никоим образом не означает что документация вообще не важна. Да и техдолг это не только документация.

Да и техдолг это не только документация.

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


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


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

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

У вас в скраме точно так же есть представление и о конечном продукте и о возможностях развития в долгосрочной перспективе.


И стратегическое планирование там тоже никто не отменял. Оно просто в некотором роде находится "уровнем выше" скрама. То есть вы выбираете ваши стратегические цели(например в виде milestone), а потом двигаетесь к ним при помощи скрама.


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

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


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

Я знаю приличное количество фирм которые без особых проблем делают свой продукт и используют аджайл. Так что не сказал бы что ваш вывод так уж и правилен.

Аджайл в первую очередь то, что написано в его манифесте. А написано вот что, из Манифеста:
Through this work we have come to value:
・Working software over comprehensive documentation
・Responding to change over following a plan
Два первых пункта напрямую приводят к возникновению техдолга.


Далее, из 12-ти принципов:
・Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
・Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Как я уже и писал, аджайл нужен для того, чтобы оттеснить конкурентов через постоянных прогиб перед заказчиком, он для этого и создавался в web индустрии.


・The best architectures, requirements, and designs emerge from self-organizing teams.
Это просто чушь. Лучшие архитектуры, требования, и дизайны возникают из большого опыта разработки, и тщательного, хорошо продуманного планирования.


Я знаю приличное количество фирм которые без особых проблем делают свой продукт и используют аджайл. Так что не сказал бы что ваш вывод так уж и правилен.

Отлично, приведите несколько примеров этих фирм и какой продукт они производят. Мне очень любопытны отзывы о качестве продукта, как и отзывы сотрудников о работе в этих компаниях (хотя последнее вторично).


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

Два первых пункта напрямую приводят к возникновению техдолга.

Не вижу почему это обязательно должно так происходить. Более того я знаю кучу примеров когда этого не происходит. В том числе и у нас на фирме. Что мы делаем не так?


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

От того что вы это написали оно не становится истиной.


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

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


Отлично, приведите несколько примеров этих фирм и какой продукт они производят.

Сомневаюсь что названия фирм вам что-то скажут, но если прямо хотите, то могу скинуть в личку.


Я вполне допускаю что умные люди "подкрутили" аджайл так, чтобы это по-факту был водопад в обличии аджайл (дабы угодить руководству)

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


И мне теперь стало интересно что вы вообще вкладываете в понятие "водопад".


Но и мой личный опыт, и сам манифест, и даже уже и сами создатели аджайла (если интересно, пришлю ссылку), говорят о вреде аджайл.

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


А ссылку можете прислать, интересно будет посмотреть.

Вот статья от одного из авторов аджайл о том, что пора бросить аджайл: https://ronjeffries.com/articles/018-01ff/abandon-1/


Вот еще парочка:
https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#7f6592bd2071
https://techbeacon.com/app-dev-testing/8-reasons-ditch-agile


Вот статья сравнивающая аджайл и водопад: https://www.pmis-consulting.com/agile-versus-waterfall/, там есть pros/cons-табличка для каждого из методов. Вот еще: https://www.pmi.org/learning/library/agile-versus-waterfall-approach-erp-project-6300


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

Вы мне эти ссылки просто по быстрому нагуглили или сами их хотя бы прочитали? :)


Там же сразу идёт ссылка на:


1

Here and in other writings, I use the quoted word “Agile” to refer to the many instances, approaches, and processes that use the word “agile” to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to “Faux Agile” for emphasis, or to “Dark Agile”, which I use to describe so-called “Agile” approaches that have really gone bad. I might refer to “Manifesto Agile” to mean the core ideas from the Manifesto, in which I still believe.


И это как раз то, о чём и я вам всё время твержу.


П.С. И я кстати нигде не утверждал что аджайл это серебрянная пуля и что все должны делать аджайл. Вполне себе бывают ситуации когда он не подходит.
П.П.С. Названия выслал.

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

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


И вы на мой взгляд являетесь ещё одним подтверждением этого правила :)

Смотрите, весь мой корпоративный опыт разработки описывается вот этим:
Waterfall
・Detailed, long-term project plans with single timeline
・Definitive and rigid project management and team roles
・Changes in deliverables are discouraged and costly
・Fully completed product delivered at the end of the timeline
・Contract-based approach to scope and requirements
・Customer is typically involved only at the beginning and end of a project ← тут все же коммуникация с заказчиком была частой.
・Linear-phased approach creates dependencies


В особенности вот это важно: ・Definitive and rigid project management and team roles.
У меня есть начальник, и он мой командир, я подчинен ему по субординации. Т.е. мне понятно под кем я хожу. Поэтому такие вот выкрутасы:
・Flexible, cross-functional team composition
・Collaborative and interactive approach to requirements
мне вообще не понятны, это просто хаос.

Смотрите, весь мой корпоративный опыт разработки описывается вот этим:

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


Поэтому такие вот выкрутасы:
・Flexible, cross-functional team composition
・Collaborative and interactive approach to requirements
мне вообще не понятны, это просто хаос.

А мне вот отлично понятны и у нас великолепно работают:)


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


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

Не путайте техтребования (описание продукта в терминах предметной области, составляется клиентом и менеджерами) и спецификации (составляются тимлидом/архитектором в терминах разработки и программирования).

Ну у нас разработчиков(как минимум сениоров/техлидов/архитектов) и местами UI/UX дизайнеров привлекают и туда и туда. Правда митинги с клиентом у нас это добровольно и можно если не хочешь, то не присутствовать.


Как в других фирмах это делается я не особо спрашивал и не то чтобы в курсе. Может быть и мы это делаем не по канону :)

Вообще да, не по канону :) Не, присутствовать может кто угодно, но про программирование говорить нельзя, чтобы заказчика не смущать. Задача-то в том, чтобы разобраться, как оно должно работать, разработать критерии приёмки и тестирования, краевые случаи применения… Т.е. внешнюю, доступную юзеру часть и условия с процессом эксплуатации.

Ну что значит "про программирование" и "заказчика смущать". У нас на счастье заказчики обычно хоть немного но тоже в теме.


Ну и кроме того им алгоритмы никто на бумажке не рисует. Просто обычно это вещи вроде "так будет дорого и/или долго, а вот так быстрее и/или дешевле".


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


П.С. Хотя это тоже сильно от клиентов зависит. К некоторым я вообще не хожу так как мне нервы дороже. А некоторые наоборот предпочитают вопросы с "техниками" обсуждать и тогда уже менеджеры большую часть времени сидят и молчат.

Из опыта, я просто ближе к железу, т.е. ещё и немного в инженерию:
1. «Делаем из анодированного алюминия или из стали» — неправильно. Правильно «Какой максимальный вес изделия? Сколько нагрузка?»
2. Неправильно «Ставим обратную связь/энкодеры?», правильно «Какая максимальная точность перемещения?»
3. «Ставим TTL?» — неправильно. Правильно «Сколько интервал между кадрами?»
Ну и так далее. Многие не понимают (честно! особенно увлеченные и начинающие), что заказчику не интересно, какие технологии вы применили, ему нужна работающая штука. На этапе эскиза получилось несколько модулей с разными характеристиками? Идём к заказчику, с ним выбираем в терминах «вот этот движок точнее, но не работает при таких-то комбинациях влажность/температура» или «так получается дешевле, но медленнее».

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


Но пока это всё более-менее добровольно и ты там не один, а с более-менее адекватным менеджером, то почему бы и нет.


П.С. Тем более после таких мероприятий у нас обычно вкусно кормят за счёт фирмы или заказчика :)

Главное чтобы в команде все необходимые роли были заняты и желательно ещё и продублированы. Ну и чтобы при необходимости человека можно было заменить.

Ну как я пытался объяснить, аджайл хорошо подходит для сверхэксплуатации разработчиков. Не нравится пахать по 12 часов в день? Давай, до свидания. Я же говорю, скорее всего аджайл применяют в потогонках (sweatshop'ах).


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


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

Но это и в водопаде делается, разумная практика. Я нередко вместе с сейлзами ездил к заказчикам.

Ну как я пытался объяснить, аджайл хорошо подходит для сверхэксплуатации разработчиков. Не нравится пахать по 12 часов в день? Давай, до свидания

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


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

Да где именно методология то техдолг порождает? Да ещё и неизбежно? Что вы это повторяете как заевшая пластинка?
Я ведь точно так же могу заявить что водопад "неизбежно" порождает техдолг, потому что есть дедлайны к которым надо успеть и они для менеджеров/начальства важнее чем какой то там техдолг…


Но это и в водопаде делается, разумная практика. Я нередко вместе с сейлзами ездил к заказчикам.

Так в том то и дело что в водопаде это иногда делается, но далеко не всегда. И нигде в "методологии" и "правилах" водопада не прописано что это надо делать.

Уже писал, вот это вот: "Through this work we have come to value: Working software over comprehensive documentation". Нигде не написано, что документация так же важна, а поэтому по факту разработчиков не беспокоит документирование ПО. Это раз. Во-вторых, излишняя гибкость приводит к тому, что никому не интересно думать на несколько шагов вперед; как результат — плохо продуманная архитектура или попросту отсутствие таковой. Только долгосрочное видение позволяет создать хорошую, расширяемую архитектуру для ПО.


Ребятки из ТокиоЩибаура все эти shortcomings знают, и скрестили ужа с ежом: https://www.toshiba-sol.co.jp/en/articles/tsoul/28/004.htm. Обратите внимание на слова: "Its most notable feature is the strict quality management built in to it through design reviews between each process (Fig. 1)". Как бы уже испытали на себе какой говнокод может породить аджайл.


Ваша аргументация из серии "Аджайл хороший, вы просто не умеете его готовить". Возможно и так. Но зачем нужна методология, которой трудно следовать правильно, и легко — неправильно? В разработке противоположный принцип используется: разрабатывай/проектируй чтобы легко было использовать правильно, и трудно — неправильно.


Так в том то и дело что в водопаде это иногда делается, но далеко не всегда.

Не иногда, а зачастую. pre-sales (оценка длительности, проясниение спецификации и коммуникация с заказчиком) также считалась частью работы инженера.

Нигде не написано, что документация так же важна

Так нигде и не написано что она не важна. И здесь речь идёт о том что лучше иметь рабочий софт без документации, чем полноценную документацию без работающего софта. Или вы несогласны с таким подходом и считаете что документация важнее? :)


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

Очень интересное утверждение, которое как минимум требует доказательства.
И я точно так же могу заявить что в водопаде вся ответственность лежит на менеджере, а не на разработчиках и поэтому им тоже "неинтересно думать на несколько шагов вперёд" и делать нормальную архитектуру :)


Ваша аргументация из серии "Аджайл хороший, вы просто не умеете его готовить". Возможно и так. Но зачем нужна методология, которой трудно следовать правильно, и легко — неправильно?

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


Не иногда, а зачастую.

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

Очень интересное утверждение, которое как минимум требует доказательства.

Очевидно: зачем думать на несколько шагов вперед, если спецификация is not set in stone, и может легко быть изменена заказчиком.


И я точно так же могу заявить что в водопаде вся ответственность лежит на менеджере, а не на разработчиках и поэтому им тоже "неинтересно думать на несколько шагов вперёд" и делать нормальную архитектуру :)

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


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

Для веба водопад плохо подходил, и для веба придумали аджайл. Но теперь аджайл пихают даже туда, куда его не надо пихать.


У вас какой стэк разработки? У меня hardcore С++, CUDA/MPI, Линукс. И мне аджайл не нужен.

Очевидно: зачем думать на несколько шагов вперед, если спецификация is not set in stone, и может легко быть изменена заказчиком.

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


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

И? Зачем им делать нормальную архитектуру если они всё равно ни за что не отвечают? Сделают как пойдёт, а остальное пусть потом менеджер клиенту объясняет :)


Для веба водопад плохо подходил, и для веба придумали аджайл. Но теперь аджайл пихают даже туда, куда его не надо пихать.

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


А то, что аджайл сейчас пихают куда не попадя, не делает аджайл сам по себе плохой методологией.


У вас какой стэк разработки? У меня hardcore С++, CUDA/MPI, Линукс. И мне аджайл не нужен.

Вам ещё несколько раз написать что я абсолютно не считаю что аджайл нужен всем и везде? Если вам он не нужен, то я не собираюсь вас уговаривать его использовать.


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

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

Печальные последствия наступают, если накопленный техдолг не обслуживается и не погашается в долгосрочной перспективе, и то не всегда (лично видел «франкенштейнов», годы и годы живущих на костылях и подпорках).

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

Вот об этом и речь, что «мы не знаем что делаем, ввяжемся в бой, потом посмотрим» Это как раз подход диллетантов без опыта. И как раз такие манифесты поощряют такие подходы. Поэтому и вопрос: кому выгодны, чтобы такие подходы работали у вас? Как раз конкурентам ;) Чтоб развалить основу — передачу знаний и наработок: зачем писать доку, если можно не писать? Написано же! Потом через время вас можно брать голыми руками, т.к. вы не владеете ни экспертизой, ни ситуацией. Вы колония…

Вы прямо тут триллер написали :)
Всё это конечно тоже имеет место быть, но проблема в описываемых вами ситуациях не в аджайле как таковом, а в самих дилетантах. Забери у них "аждайл" и заставь делать водопад и ситуация на мой взгляд не особо изменится.


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


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

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

И чем в этом плане аджайл отличается от водопада? Почему когда мы делали водопад мы не были "рабами", а когда перешли на скрам, то внезапно ими стали?

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


Если нормальных методичек нет, а все эксперты не могут сказать ничего, кроме того, что у всех кругом Faux Agile, то эта методология для продуктивной работы не годится.

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

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


Ну и мы например на старте брали человека со стороны чтобы он смотрел всё ли мы правильно делаем и потом таких людей пару раз приглашали для контроля/консультации.


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

Ну и мы например на старте брали человека со стороны чтобы он смотрел всё ли мы правильно делаем и потом таких людей пару раз приглашали для контроля/консультации.

Интересно, сколько человек со стороны вникал в вашу ситуацию? У нас, по опыту, нужно от 3х месяцев, т.е. человек должен полностью погрузится в команду и область, т.е. работать у нас. Пару раз начальство присылало коучей, ну и? Как пришли, так и ушли. Сейчас опять вместо тех лида или старшего разработчика взяли Scrum Mastera… Графики красивые рисуем, но как не успевали заказчику отдать вовремя, так и не успеваем, т.к. тупо не хватает людей на хотелки.
Интересно, сколько человек со стороны вникал в вашу ситуацию?

Он у нас полгода где-то был в первый раз.


Сейчас опять вместо тех лида или старшего разработчика взяли Scrum Mastera…

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

Что значит "прогиб под клиента"? Задача компании удовлетворять потребности заказчика, и вчера он хотел зеленый дом, а сегодня — красный, то лучше бы узнать об этом в середине покраски и сразу начать делать красный дом, а не доделывать зеленый со словами "ну мы же договорились".

Уже проходил такое, заказчик моего первого работодателя постоянно менял спецификацию ПО, а разработчики выполняли все хотелки заказчика. И заказчик отказывался платить пока не получит конечный продукт. Результат был таким: миллионные долги (в долларах США), из-за чего компания оказалась на грани банкротства. Часть разработчиков сократили.


Вот результат прогиба под заказчика.

Это результат прогиба И контракта с фиксированной ценой.

Поэтому я работаю в продуктовых компаниях. И там аджайл отлично работает. Тут у вас два варианта, либо вы подстраиваетесь к желаниям клиентов, либо они уходят к конкуренту. Шанс прогореть намного выше во втором случае.

И, позвольте угадаю, занимаетесь Вы веб-разработкой, так?

Учитывая, что основное разбиение это веб, десктоп и геймдев, и второй практически мертв, то вроде бы это очевидно, нет?

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


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

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


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

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

Эмбеда тоже немного.

Я бы так не сказал. Уже сейчас это приличный процент, который кстати постоянно растёт.


B2B сервисы это тоже веб.

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


Если у вас сайтик с десятком кнопок по которым программа что-то делает то это скорее тоже веб.

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

Ну вот у нас так и есть. Есть мобилка, сайт, всё это триггерит какие-то B2B сервисы. И это считается вебом. Я знаю потому что я сюда устраивался.

Видимо зависит от фирмы. У нас идёт чёткое разделение на бд, бэкэнд, веб, мобайл, десктоп и эмбеддед.


И веб это чисто фронтэнд и сама страничка.

У аджила и скрама есть описание когда они помогут и когда они НЕ помогут, а помешают?
Если нет — их трудно воспринимать серьезно

Есть рекомендации когда скорее стоит использовать аджайл, а когда скорее не стоит. Так же есть рекомендации какая конкретная аджайл-методика скорее подходит в какой ситуации.


И аджайл/скрам это не серебрянная пуля и они подходят далеко не для всех фирм.

>>>И аджайл/скрам это не серебрянная пуля и они подходят далеко не для всех фирм.
Это нужно высечь в граните
Окликнулась как-то на резюме одна контора. Читаю описание вакансии созваниваемся, говорю мол вряд ли я вам подхожу, я C++ ник а у вас тут Ява, девочка такая — там писать на Яве не надо — только читать, что написали другие (должность была вроде аналитика по улучшению кода/архитекруты), дрижой пользоваться умеете? Нет говорю.
Проходит несколько дней, девочка звонит снова, говорит — у нас проблема была с Джирой — вы не умеете ей пользоваться?
То-есть знание ЯП им до лампочки, а Джира возведена в карго-культ ;)
Ну потому что Джирой же даже она может пользоваться… Так что что можно сказать о человеке, который даже этого не умеет?
Что он Джиру никогда не видел и смотреть не собирается, раз отказывается от вакансии так-как не является гуру Явы?
Только когда писал ответ дошло, что это был сарказм — тонко.
А вообще слово аналитик в названии должности нужно запретить законодательно — это имя слишком перегружено

У меня постоянно ощущение, что открыли фабрику по клонированию дураков. Не может быть, чтобы их столько естественным путем народилось.

Просто коммуникации стали доступнее, вот мы и стали заметнее :)
А то. Если раньше, чтобы в области, в которой я не разбираюсь, дать совет безбрежного масштаба и не меньшей глупости я мог только лично, на посиделках с друзьями, то теперь у меня Интернет есть! Серьёзно, если раньше в состоянии умственной расслабленности, которая бывает у всех, чтобы донести своё мнение надо было затратить силы: пойти или написать письмо, то теперь в кармане доступ к широковещательному каналу.

"Например тимлид должен нанять программиста, лучшего чем она" — что за перевод — в оригинале — engineering manager — никак не тимлид — но не это главное — вопрос к автору — как можно оценить лучшего, если твой уровень ниже. Кажется, обычно более опытный оценивает менее опытного
И кстати, кто это она

who is a better programmer than she is
Так и было в оригинале, я ничего не менял :) Диверсити, все дела.
Это 'generic she', оно же 's/he' — переводится как 'он/она'.

Обычно в таких случаях говорят they, разве нет?

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

Но я использую s/he. Не потому что считаю they грамматичски некорректным, а потому что не верю в историю о 100500 полов. S/he — чётко показывает, что тут либо He, либо She — и нам неважно кто. They — это архаизм, вытащенный откуда-то SJW и превращённый в фетиш.

Ну так он не одно столетие некорректным и считается :) И мне всегда казалось, что используется он просто чтобы не городить неуклюжие конструкции типа вашего s/he (кстати, как вы это произносите)? Но справедливости ради надо сказать, что с учетом небинарных гендеров я на этот вопрос никогда не смотрел. Пожалуй, буду тоже использовать they, чтобы уж точно никого не обидеть (граммар наци не в счет).

Пожалуй, буду тоже использовать they, чтобы уж точно никого не обидеть (граммар наци не в счет).
Не удастся. SJW не для того, однако, существуют, чтобы вы могли так просто взять — и соскочить с иглы. Или вы эту историю пропустили?

Вот прямо так написано: Explicitly avoiding using someone’s pronouns because you are uncomfortable is a way of refusing to recognize their identity and is a violation of the Code of Conduct.

Это Stack Overflow, блин, не форум феминисток! А что в результате человек 20 модераторов свалило — так это они просто ни черта в толерантности не смыслят.

В общем JAGODIBUJA, как обычно, зрит в корень:
Неужели не видели?

Удовлетворить «хотелки» SJW нельзя — любое ваше действие, равно как бездействие, они могут превратить в ущемление чьих-то прав.
или так, его уже давно переводят
image
Вот прямо так написано: Explicitly avoiding using someone’s pronouns because you are uncomfortable is a way of refusing to recognize their identity and is a violation of the Code of Conduct.
Не вижу проблемы. Называть человека так, как он просит его называть — элементарная вежливость.

Не удастся. SJW не для того, однако, существуют, чтобы вы могли так просто взять — и соскочить с иглы.
Ну в случае StackExchange таки удастся — там явно сказано
“Prefer gender-neutral language when uncertain.”
и
Q16: May I use they/them by default?
Yes, but be prepared to make adjustments if so requested.
Ну в случае StackExchange таки удастся — там явно сказано
Через пару лет такое обращение станет опять угнетающим.
на примере дрейфа понятий черный/негр/афроамериканец и калека/инвалид/люди с ограниченными возможностями. Каждый раз новый термин был призван убрать негативную коннотацию предыдущего
Не вижу проблемы. Называть человека так, как он просит его называть — элементарная вежливость.
А я вижу. Чтобы называть человека «так, как он просит его называть» — нужно провести опросы, где-то это зафиксировать, создать комиссии, которые будут вот всё это рассмастривать и прочая-прочая.

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

Ну в случае StackExchange таки удастся — там явно сказано
“Prefer gender-neutral language when uncertain.”

и
Q16: May I use they/them by default?
Yes, but be prepared to make adjustments if so requested.
Что там сказано и что там сделано — таки разные вещи.

Когда Моника сказала, что местоимения — в общем-то в принципе штука необязательная и вместо he/she/they/whatever можно просто употребить имя персонажа, к котрому обращаешься — её тупо выгнали. За нарушение вот этих самых правил (которые ещё и приняты в тот момент не было). Ибо нефиг. Думали от вас на Stack Overflow хотят знания математики или там программирования? Фиг — самое важное, чтобы вы мужика в платье по имени-отчеству не называли, а говорили «она» (ну или «оно» — но только так, как этого от вас просили)… и шоб не путали никогда!
Не вижу проблемы. Называть человека так, как он просит его называть — элементарная вежливость.

Если человек на SO попросит называть его «master of slaves», нужно ли выполнять эту просьбу?


Или, если вы любитель поиграться с логикой, что делать, если у него в этом поле будет «please don't call me by my preferred pronoun»?

Кстати, на первый вопрос официальный ответ уже имеется — если ваши pronouns модератору не по вкусу — то можно и не называть. Правда, тогда это строго говоря "denying your lived experience" и прочий джаз, но модератор может не вмешиваться. Эта вся ситуация как с религиозными писаниями, там уже толкователи появляются.

Тогда вообще непонятно. Ну не по вкусу какому-нибудь модератору называть людей местоимениями с подразумеваемым гендером, отличным от данного по рождению. Или вообще по каким-либо местоимениям (за что Монику-то выгнали тогда?).


Или, что ещё круче, не по кайфу называть кроме как he. Потому что, как модератору известно, в интернете девушек нет.

А тут фишка в том, что в интернете есть огромные словари этих нео-местоимений, и модератору, как я понимаю, будет разрешено обращаться к своему вкусу только если вашего местоимения в словаре нет (что, кстати, иронично, т.к. отсутствие чьих-то уникальных как снежинка местоимений в обыкновенных словарях всегда называется большой проблемой). Впрочем, отсутствие в словаре элементарно решается — созданием собственного словаря+1 где-нибудь на тумблере, а как решается вопрос с мусорными словарями — пока неясно, придётся ждать версии словаря с личными местоимениями за авторством 4chan, видимо.

Весело.


Жаба, гадюка и их сложные отношения.

Называть человека так, как он просит его называть — элементарная вежливость.

Элементарной вежливостью это было до того, как за отказ подчиниться начали выгонять. Согласитесь, тяжеловато быть искренне вежливым когда за невежливость вас линчуют.
Если прочитать ответы работников StackExchange (не модераторов, а именно людей на зарплате) на многочисленные вопросы про новую политику, то ясно видно, что правил, с этим связанных, по факту нет. Например, если в длинном чате вы пользуетесь юзернеймом, и при этом оный юзернейм неделю назад просил вас обращаться к нему "кхия" (и не забудьте это слово просклонять правильно, а не то), а вы забыли (потому что таких же юзернеймов вы, как человек, отвечающий на тупые вопросы, за неделю были вагон и тележка), юзернейм может пожаловаться на вас модераторам. И начиная с этого момента всё зависит исключительно от того, был ли модератор в хорошем настроении сегодня, т.к. правила на этот счёт имеют два противоположных утверждения. Если настроение было плохое — ну, создавайте другой аккаунт на SO, предыдущий-то всё. Случай, разумеется, утрированный, но общее ощущение от новых правил такое, что смысл не в том, чтобы все жили как завещал кот Леопольд, а в том, чтобы всегда под рукой была благовидная палка, которой вас можно выгнать, если что.

В англоязычных коммьюнити, озабоченных дивёрсити (аж в рифму, лол) можно троллить тех, кто говорит s/he, тем, что они слишком бинарны и нетолерантны к неклассическим гендерам.


Получается, кстати, довольно забавно.

Это ладно. В Германии после всех этих дебатов и чтобы быть потолерантнее некоторые фирмы стали в вакансиях писать (m/w/d), есть (männlich/weiblich/drittes) оно же на русском (мужчина/женщина/третье). Но кто-то "расшифровал" это как "männlich weiß deutsch", то есть "белый немецкий мужчина". И теперь это стало местным мемом :)

Всего одно третье?!

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


Раньше просто в таком случае писали только (m/w).


П.С. В данном случае "третье" можно понимать как "иное". Можно сказать особенности языка.

То есть, весь остальной спектр гендеров настолько неважен, что вы его упаковываете и ставите на тот же уровень, что и один из классических гендеров?!


Ладно, надо прекратить играть в обиженку, а то вдруг понравится, привыкну ещё.

То есть, весь остальной спектр гендеров настолько неважен, что вы его упаковываете и ставите на тот же уровень, что и один из классических гендеров?!

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


П.С. И большинство фирм вообще ничего не указывают если нет конкретных ограничений.

Интересно, если у нас начнут писать (м/ж/оно) — какая реакция у третьих будет? )
можно троллить тех, кто говорит s/he, тем, что они слишком бинарны и нетолерантны к неклассическим гендерам.
Любой каприз за ваши деньги. Хотите чтобы я запоминал, что Вася сегодня не «он», а «кхия» — платите. Не хотите платить — ну так я вас читать вообще не заставляю.

P.S. И да, если работодатель готов за это платить — то это другая история. То есть понятно, что вот это вот увлечение разноцветием полов и прочим — одного поля ягодки с постоянно меняющимися ГОСТами на чертежи… но если для вас важно, чтобы торерантность соблюдалась, а будут ли падать ракеты — неважно… ну значит так тому и быть. Но если я должен этим заниматься бесплатно… извините…

Вы не поняли.


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

Там, как правило, есть внутрикорпоративный чатик, где все общаются.
Все? Нет, всех там наверняка нету. И меня там не будет, скорее всего. Особенно если там будет насаждаться «толернтность» и «инклюзивность». И уж тем более если там появится корпоративный профайл со 100500 гендерами и расами на каждого сотрудника.
Добавлю в список:
Нанимать оптимизатора бизнес-процессов, который их оптимизирует основываясь на работе с руководством, а не с людьми в полях.
Обязательно внедрять технику applе: всем по планшету, смартфону, макбуку.
работники начинают заниматься диджейством и всякими другими фишками и ништяками
В офисе все начинают носить бороду
Совещания проходят каждый день и занимают от 1 до 3 часов
Обязательные видеосовещания с филиалами — так же идут от 1 до 3 часов
Приглашается Бакшт!
Так же все начинают хоить на успешный успех!

Да, если даже красивые девочки с ресепшена начинают носить бороды, то с компанией что-то не в порядке

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

Ага. Это означает что уже никто не будет вкалывать в четырьмя мониторами присоединенным к одному десктопу. А все разделятся на две части. Одна половина будет елозить по тачпаду а другая задумчиво ходить по офису поглаживая тачскрин в бесконтактных наушниках.

Всё таки это зависит от того, кому выдавать и для чего.
Для менеджера в полях бегающего ради отчетов ежедневных в вашей системе — да, по мне планшет от эпла будет лучше, чем планшет на других ос)
Как хороший пример, кстати, Приватбанк. Везде где был у тех кто работает с клиентами айпады. Дуракоустойчиво, надежно, взаимозаменяемо.
Может делать фото и принимать подписи.
Реальный софт крутится на серваке через веб-морду.

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

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

Нашел возможное происхождение выражения bozo explosion:
www.urbandictionary.com/define.php?term=Bozo%20Bomber
The Bozo Explosion was possibly coined by Steve Jobs at Apple:

“Actually, Steve believed that A players hire A players—that is people who are as good as they are. I refined this slightly—my theory is that A players hire people even better than themselves. It’s clear, though, that B players hire C players so they can feel superior to them, and C players hire D players. If you start hiring B players, expect what Steve called “the bozo explosion” to happen in your organization.” — Guy Kawasaki

В связи с этим вспомнилась известная поговорка «рыба гниет с головы».
Вспомнилась известная книга:
Сирил Паркинсон. Законы Паркинсона (полный текст)

Вкратце:
Закон Паркинсона — Википедия
НЕПРИЗАВИТ (в другом варианте перевода — БЕСПОЗАВИЯ)

Состоит из трёх стадий.

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

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

3. Во всём учреждении, снизу доверху, не встретишь и капли разума. Признаки — самодовольство сменяется апатией.

В общем, ничто ни ново под луной. :)
А есть ли у кого примеры, когда начавшиеся одебиление потом удачно прошло? Я про компании которые выпускают какой то конкретный продукт и у которых есть много конкурентов.
Мне-то кажется, что это начало конца для них и выздоровевших не наблюдал, но может я ошибаюсь?
Про IBM интересно читать. Там 1993 там очень удачно CEO наняли и дали работать, тот разогнал значительную часть бюрократии, продал традиционные, но убыточные направления, в итоге доходы поползли вверх.
Вообще, «раздебиливание» во многом похоже на внедрение CRM: для успеха должны быть желающие успеха начинанию и вверху (работают толкачами), внизу (демонстрируют эфект и реализуют «воспитание коллективом» по Макаренко).
Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю


Не знаю как у кого… но у меня если на работе начинают бухать просто так — это явный признак скорого «дна».
Но в пятницу после работы, часто сочетая с бэклогом, или после закрытия проекта — нормально. Хуже, когда каждый день у кого-то день рождения или иной праздник — все собираются на обеде посидеть и задерживаются в лучшем случае на часок.
А какие вопросы стоит задать на собеседовании, чтобы не вляпаться в такую компанию?
* Субьективно — если тебя собеседует эйчар это уже плохой знак.
* Если эйчар делает что-то более чем первичный фильтр — ещё хуже.
* Если твоим боссом будет менеджер который сам не технарь это плохой знак(исключение — если это сооснователь или глава филиала)

Срачегонные критерии:
* Много девушек, особенно на высоких должностях. Девушки на порядок больше любят более стабильные и бюрократичные компании где все четко расписано.
* Друзья и родственники начальства в компании, только если это не кофаундеры
* Компания использует технологии которой ты бы сам не стал пользоваться в их ситуации
** Бонусные очки — если это продиктовано чисто бизнес-соображениями, типа того что у вас Microsoft в партнерах и потому пользуемся только тем что поддерживает Ажур
* Любовь к любым государственным статусам, регалиям, бумагам итд, ну и ватность в целом. К ней склонен тот тип руководителя который и разводит у себя в компании вертикаль начальник-дурак. (спроси чей Крым, ага)
* Любовь к продукции Эппл, Майкрософт или любой другой без понятной причины. Скорее всего это потому что «никого ещё не уволили за то что он купил IBM»

Дисклеймер:
Все предыдущее безусловно плохо только в контексте bozo explosion. Большинство людей работают в компаниях где он уже произошел, большинству даже нравится.
Не очень понятна целевая аудитория статьи. К кому автор обращается?
Если к боссам, так они это не читают, слишком поверхностно.
Если к сотрудникам, так у них полномочий нет что то менять, они же не боссы.
Или так, потешить самолюбие рядовых, которые могут представить, чтобы они сделали если бы были боссами?
Для рядовых один совет: замечаете срань вокруг и не видите возможности карьерного роста до позиции, где сможете на что то влиять в этой компании, попытайтесь найти работу в компании более здоровой.

Одебиливание? В больших компаниях это происходит повсеместно!
Вспомните лабы в институте, больше трех — эффективнось падает!
Джефф Безос сформулировал правило дву пицц, но но гораздо ранее оно появилось у воров.
Колода вроде — 5 человек, каждый обладает уникальным навыком — щипач, медвежатник и т.д.
Отсюда и "шестерка" — "лишний" в наборе, которого и пускали на рисковые дела.


Это так, из передачи "следствие вели с Каневским".


А по сути — одебиливние — это следствие глобализации — "скованные одной цепью" — помните?


Когда в любом уголке планеты магнитики с с названием и символом посещаемого места имеют надпсь "Made in China" на обороте.
Кроме еды в ресторанах, невозможно приобрести ничего произведенного локально в посещаемом регионе.


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


В общем — одебиливание — оно повсеместно, и в головах, подобно "разрухе" у Преображенского.

Еще один заметил способ одебиливания — акцент на средства, а не на цели. То есть человек должен в совершенстве знать язык программирования, но не должен задаваться вопросом «для чего ?», «для каких целей?». В результате проекты, в которые его ставят становятся все более невыносимыми.
А по-моему, знать язык, но не знать предметную область, в которой будет применяться программа, нормально для программистов нижнего уровня при грамотной работе вертикали командования. Думают менеджеры, архитекторы и тимлиды, а софтогонный агрегат имеет на входе что-нибудь типа UML или спеки.
Для программиста имеет смысл качество проекта и качество жизни.
У меня было несколько друзей, с которыми можно было интересно поговорить, но при переходе на отстойные проекты они перестали понимать анекдоты и все время смотрят в пол. И только твердят — учи джаву, учи джаву.
Имхо, это довольно нормальный работающий подход, но в том случае, если недумающий исполнитель не принимает решения самостоятельно и не будет (!) их принимать в будущем. Иначе получается так, что сначала исполнитель просто работает, через некоторое время начинает постепенно принимать ответственные решения, но при этом извне компании его бы не взяли на эту должность, так как нет нужных знаний и адекватности. Любимый пример — информационная безопасность: смотришь на какую-то проблему, спрашиваешь, кто вообще додумался так делать. Выясняется, что это делал некий сеньор, который год назад был мидлом, а три года назад пришёл в эту компанию джуном после универа. Внутренний опыт далеко не всегда говорит, что сотрудник может принимать решения.
Вы серьезно считаете, что можно дать несколько простых советов, и это избавит компанию от скатывания к посредственности?

Если внимательно почитать текст статьи, то она носит скорее характер иронии. И советы также это не столько советы, сколько ирония на тот счет как дела обстоят на самом деле.


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


Но есть люди которые могли бы быть заинтересованы — это владельцы бизнеса. В отличие от пафосных менеджеров среднего и высшего уровня (иногда они тоже всего лишь наемные рабочие но на сказочных окладах). Однако в контексте этого термина (взрыв Бонзо) обычно подразумевают слетевшее с катушек среднее звено менеджмента.

Например тимлид должен нанять программиста, лучшего чем она

Опа, тимлид-гендерфлюид!
Понятно, что это дань феминитивщине, — что теперь дефолтное местоимение стало she, но
1) понятно и другое: род глагола надо было согласовывать и с тимлидом, и с "ней"
2) давайте не будем страдать общечеловековой фигнёй

Только мне это напомнило Российскую вертикаль власти?
Госслужба в этом смысле обычно мертворожденная во всех странах.
Ну и ортодоксальное христианство(католичество/православие) тоже.
Уместно тут будет оставить ссылку на классику, написанную, когда еще ни о каких компьютерах вообще не слыхали:

«Законы Паркинсона»

О том, как бронзовеют и умирают бюрократические организации
Сюда же добавлю «Бюрократию» Фон Мизессаю.
ИМХО, антиодебиливающие советы ни о чем. Вы просто добавили очередные лозунги. В больших организациях проблема не в лозунгах — их как раз всегда хватает. Умелый бюрократ любой лозунг сможет использовать в своих личных целях. И чем больше лозунгов — тем проще бюрократу.
Проблема больших организаций в отсутствии адекватных институтов (подразделений, позиций, ролей) которые бы эффективно противостояли обюрокрачиванию. Института государственной власти это касается в первую очередь.
Мне кажется, это скорее сборник маркеров «Пора уходить из компании. Дальнейшая работа может быть хлебной, но при этом бессмысленной и бесполезной»
Кому как. Зависит от того, что нужно от работы и в чем ее предмет. Бывают в таких компаниях такие руководители, которые могу защитить (сгладить эффекты) подчиненных от влияния сверху. Но как правило такие руководители высоко не идут — ценны на своем месте. Выше важен другой скиллсет.
Для некоторых такие компании — основной предмет работы. Например, внедренцы\разработчики систем ERP вроде SAP. Сплошь такие клиенты (особенно на пространстве бывшего СССР).
Я работал всё больше в мелких-средних компаниях.
Так, что и симптом попроще, хотя смысл тот-же:
основатель-владелец покупает-строит дом-дачу-яхту.

Какаой-то странный симптом… То есть сотрудникам можно покупать-строить дом-дачу-яхту, а основателям и владельцам нет? Или вообще никому нельзя?:)

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

И самым богатыми людьми в фирме должы быть уборщица и мальчик на побегушках? :)

А в чём эксплуатация?


Почему бы рядовым сотрудникам, если они считают, что их эксплуатируют, не стать таким вот владельцем? Ведь там не жизнь, а раздолье — знай себе, сиди, эксплуатируй.

А это все сговорившийся правящий класс использует специальные методы, чтобы не дать им выбиться в руководители. Не хотят терять хлебное местечко!
Полностью согласен с автором, но во многом все зависит от руководства и хозяина компании, будет больше платить ставить интересные задачи и коллектив хороший соберет тогда.
UFO landed and left these words here
Например тимлид должен нанять программиста, лучшего чем она


Понятно, что в современных США согласовать существительно с «он» это сексизм и дискриминация, даже «they» уже не катит, но в русском языке, даже если это перевод с американского английского, тимлид это пока ещё он.
  1. "Настаивайте чтобы менеджеры нанимали лучших менеджеров чем они сами". Что значит "настаивать"? Если повторять это настойчиво и на каждом совещании, то смело можно добавлять еще одним пунктом к одебиливанию. В подавляющем большинстве компаний менеджеры не заинтересованы нанимать людей сильнее себя. Там, где это не так, одебиливание компании точно не грозит. А где так — существует ли хитрый механизм, который засвталял бы менеджеров нанимать людей сильнее себя? Я про такой механизм ничего не знаю. Единственный крайне рискованный ход — это властителю или группе властителей компании жуть как захотеть раздебилить свое детище. Для этого не ошибиться в поиске нужной команды консультантов, не пожалеть на это кучи денег и 3-5 лет геморроя и быть готовыми заменить 50% персонала.


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


  3. Не нанимайте с излишком. Думаю, этим могут болеть только госкорпорации. А в большинстве из них дебилизм непобедим и дергаться бесполезно.


  4. Я бы предложил намеренное сдерживание продаж. Это на падающем-то рынке????


Ещё один пунктик: перекуп человека из Очень Крутой Компании с MBA (в идеале — с 12 пункта) за х2 его зп, о чём должно сообщаться с придыханием: «Мы перекупили продажника из <технологическая компания> в нашу <компания продажи одежды> с MBA! За зп как у всего нашего отдела! Вааау!!!!»
Ну и как же без карго-культа? Всё начинается с митинга «Я тут был заграницей в Риц Карлтон и встретил топа из ххх, они используют продукт XYZ — нам он тоже необходим! С понедельника срочно все переходим на XYZ и начинаем жить по-новому!» — при этом оценки «зачем продукт, почему его используют, какие у него слабые стороны» естественно не происходит.

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

Only those users with full accounts are able to leave comments. Log in, please.