Как-то больно смотреть как крутая, эффективная и боевая компания скатывается в тупую посредственность и середнечковость. В Кремниевой Долине мы это называем «одебиливанием» (bozo explosion). Этот процесс кажется неизбежным для любой компании, пришедшей к успеху, обычно после нескольких лет после IPO. Цель этой статьи — предупредить, если не предотвратить это процесс в вашей компании.
Первым делом нужно понять началось ли уже одебиливание. Вот десять признаков, по которым можно понять насколько все запущено:
1. Самые популярные слова в вашей компании это «партнерство» и «стратегия», особенно когда они идут вместе — «стратегическое партнерство». Особый градус добавляет название «стратегическими» различные бессмысленные и хаотические движения.
2. Для того чтобы наладить эффективную коммуникацию в компании и составить для нее миссию, менеджмент сваливает в Риц Карлтон за границу.
3. Миссия, которую составили в предыдущем пункте, состоит больше чем из двадцати слов, два из которых это «стратегический» и «партнерство».
4. Над контролером стоит контролер, которого контролирует другой контролер.
5. Биоритмы вашей стоянки выглядят примерно так:
8.00 — 10.00 — нищебродских корейских иномарок больше чем пафосных немецких тачек.
10.00. — 17.00 — крутых немецких тачек больше чем нищебродских корейских иномарок.
17.00 — 22.00 — опять нищебродских корейских иномарок больше.
6. Ваши ХРюши требуют MBA даже от кандидатов на уборщиц. На технологии, которым появились не более 4 лет назад, они требуют опыт от 5 до 10 лет.
7. Время теперь считается важнее чем деньги, поэтому у вас в компании есть свое кафе, фитнес клуб и парикмахерская для собачек. Первое что показывают гостям в вашей компании это кафе, фитнес клуб и парикмахерскую для собачек.
8. Земфира поет на вашем новогоднем корпоративе.
9. Кто-то получает деньги только за то, что он ведет блог.
10. Успехи конкурентов бесят вас больше чем потеря клиента.
(Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю)
Добавлено от читателей:
11. У вас есть прослойка менеджеров среднего звена, работавших раньше в известных компаниях (типа «Пятерочки») которые любят собирать совещания по поводу и без, а также назначать «лидеров проекта». (Из первых рук).
12. Вы нанимаете очень известную консалтинговую фирму, которая выделяет вам MBA с годом опыта реструктурировать стратегию всей вашей компании.
13. Девочки на ресепшне все красивее, пафоснее и глупее.
14. Ваш CEO и CFO тусуются больше в телеэфире чем в офисе.
Кажется очень знакомым? Не пугайтесь, вы не одни. Вот что можно попробовать сделать в данной ситуации:
Настаивайте чтобы менеджеры нанимали лучших менеджеров чем они сами:
Например тимлид должен нанять программиста, лучшего чем она, уж точно не хуже. Между прочим тот же принцип должен соблюдаться еще с этапа поиска CEO для компании советом директоров.
Искореняйте высокомерие и снобизм
Высокомерие проявляется в двух принципиальных вопросах: во-первых когда ваши сотрудники называют конкурентов «недалекими», «клоунами» или просто «идиотами». Второе, это когда ваши сотрудники начинают верить в «Великое Предназначение» — что вашей компании предназначено судьбой завоевать тотальное доминирование на рынке. Вряд ли ваши конкуренты идиоты и деревья обычно не растут до неба.
Не нанимайте с излишком
Нанимайте меньше людей, чем вам кажется нужно для экспоненциального роста, которого вы конечно же считаете что достигнете. Когда вы открываете множество вакансий, реагируя на быстрое расширение, вы делаете ошибки. К сожалению многие компании следует практике «давайте наймем побольше, а там разберемся уже».
Не распухайте
Это обратная сторона прошлого пункта об ограничении найма. Я бы предложил намеренное сдерживание продаж. Оставаться небольшим и эффективным это вполне приемлемая стратегия управления. Ну или хотя бы посчитайте действительно ли нужно нанимать дополнительный персонал для открытия нового направления, закрытия определенной сделки или слияния.
Смотрите на человека, не только на резюме
Цель рекрутинга это создание команды отличных работников. Один из признаков хорошего работника это соответствующее образование и/или опыт работы. Однако наличие этого еще не гарантирует мастерство и компетентность кандидата. Найм «клоуна» с крутым резюме может потянуть вниз других, нормальных работников, и повышает вероятность найма других «клоунов». Отказ отличному кандидату потому что у него не настолько крутое резюме, возможно не так критично, но тоже является ошибкой.
Вносите разнообразие
Некоторые компании выглядят как загоны для овечек Долли, как будто всех работников клонировали. Например у всех есть докторская. Или все росли в семье из среднего класса. Или ходили в одну секцию дзюдо. Или все учились в «Лиге Плюща». В конце концов получается какая-то армия клонов. Когда это случается, это значит что форма превалирует над содержанием, и людей ценят не за их поступки и действия, а за то насколько они соответствуют форме. Эта дорога ведет глубоко вниз.
Сокращай и соединяй
Вы должны принимать меры по исправлению положения и увольнять людей, если это необходимо, по мере возникновению проблем. Вы может быть думаете «Ну давайте подождем, может он исправится, наша статистика еще неплоха». Но это несправедливо ко всем остальным участникам процесса. Если есть проблема — нужно ее решить, если ты не можешь ее решить, то сделай это чужой проблемой — избавься от нее. Образцовость должна быть корпоративным стандартом.
Комментарии (251)
xDimaRus
19.10.2019 01:32+8Ну тут или одебиливание или мясорубочка. А хуже всего динамичные компании. Они и то и то.
mkll
19.10.2019 08:56+14Хуже динамичных только «динамично развивающиеся».
RouR
19.10.2019 09:40+25С молодым и дружным коллективом. Но в вакансии потребуем стрессоустойчивость.
mapron
19.10.2019 13:05+13Обычно «дружный коллектив» подразумевает «мы тут дружим, а ты чужой хер, мы тебя не звали», поэтому и стрессоустойчивость.
goga_kk
19.10.2019 14:15+40Волки загнали собаку, окружили, хотят сожрать. Собака просит не убивать её, взамен обещает помогать загонять овец и пр.
Волки подумали и оставили собаку в стае. Два года она им помогала, всему учила, показывала места, охотилась вместе с ними…
Настала особенно голодная зима, охоты неудачные, волки голодные, отчаявшиеся. Что делать? Решили всё-таки сожрать собаку. Сожрали. Косточки похоронили. Поставили надгробие. Думают, как подписать, от кого? «От друзей»? Так вроде какие какие друзья, раз сожрали… «От врагов»? Так 2 года вместе бок о бок жили, охотились, никто в обиде не был… Подумали и написали «От коллег».
goga_kk
21.10.2019 11:21Еще возможен вариант, когда в начале наоборот все очень круто и дружелюбно, но если через время бывший новичок будет показывать лучшие результаты со всеми вытекающими… вот тут и понадобиться стрессоустойчивость.
Хотя как это можно проверить при приеме на работу для меня загадка. Наверное можно, но почти нигде не проверяют.
0xd34df00d
19.10.2019 05:07+6Стратегии, партнёрства и прочие миссии от меня далеко, а код и решение задач — нет. Так что для меня основной признак одебиливания — NIH-синдром вкупе с уверенностью, что у нас работают лучшие инженеры, одной левой способные написать систему сборки, систему версионирования исходников и какой-нибудь распределённый кэш на сдачу.
khim
19.10.2019 17:02Осталось только понять почему Андроид от компании, в которой действительно написали систему сборки (и не одну), систему версионирования исходников (тоже не одну) и состряпали распределённых кешей (в количестве) стоит на миллиардах устройств, а операционки от компаний «этим не страдающих» — всё загнулись…
vikarti
19.10.2019 17:14+3Потому что эта компания купила Android, Inc за 130 млн долларов и надо было всего лишь не угробить? Задачу «не угробить» облегчили себе тем, что выложили Андроид в исходниках под лицензией которая допускает правку всеми? (Play Services появились уже потом да и существовать без Play Services в принципе можно — с кучей проблем но можно — живет ж Амазон)
khim
19.10.2019 17:26-1Ну купили они не операционку, а команду. Никакой операционки на момент продажи у них не было. Были кой-какие демки, ещё даже не было решено на каком языке «всё вот это» писать… По вашей логике получается, что «одебилевшая компания» — это примерно такая, которая может взять дворовую хоккейную команду, чемпионов Жмеринки и сделать их чемпионами мира… а тогда точно ли к такому применим эпитет «одебилевшая»?
Не очень понятно почему такого состояния нужно бояться и с ним бороться…ovel1
20.10.2019 13:26+1Одебилевшая — это когда бы они купили вот эту команду, а потом половину сократили, на освободившиеся позиции набрали дислексиков из Индии, работающих за еду и сделали ребрендинг с выпуском новых памфлетов. Оставшаяся половина стала бы работать под угрозой кнута, продукт скатился в бы говно и они бы уволились и пришли к началу точно такого же цикла в другой компании, т.к. держатели MBA тоже долго на одном месте не задерживаются.
0xd34df00d
19.10.2019 20:12+9А, спасибо, что напомнили. Считать себя гуглом и копировать их паттерны тоже один из признаков.
А оценка даже снизу вашего интеллекта позволяет заключить, что вы вполне в состоянии найти, почему ваш тезис не подходит как контр-аргумент.
khim
20.10.2019 02:04+1А оценка даже снизу вашего интеллекта позволяет заключить, что вы вполне в состоянии найти, почему ваш тезис не подходит как контр-аргумент.
Вы меня переоцениваете. Всякие собственные системы сборки и кеши в Гугле были ещё когда там человек 500 работало… Так почему Гуглу можно, а вам — нельзя? Где грань?
Нет, понятно, что если в компании работает человек пять, а она мнит себя Гуглом и разрабатывает систему, которая будет управлять миллионом компьютеров… Тут что-то явно не так… Но если в кампании 100 человек? Или 1000? С какого момента это становится нормальным?0xd34df00d
20.10.2019 19:12Потому что гугл делал систему сборки 20 лет назад, когда с системами сборки в мире C++ всё было очень плохо.
Если вы сегодня будете делать систему сборки, то вас обгонит компания, которая не тратит на это время.
Ну и ещё есть разница между необходимым и достаточным, всякие чуть более неопределённые вещи вроде того, что мы не знаем, сколько компаний, делавших свои системы сборки, так и не стали гуглом, и так далее.
Alcpp
19.10.2019 22:41+1Знавал компанию, в которой написали собственный логгер, хотя можно было обойтись стандартным. И еще пару мелочей в таком же духе.
Так и не стали Андроидом :).
DarthVictor
20.10.2019 20:39написали систему сборки (и не одну), систему версионирования исходников (тоже не одну) и состряпали распределённых кешей (в количестве) стоит на миллиардах устройств, а операционки от компаний
Почему Вы думаете, что это связано? Операционки от MS и Apple тоже стоят в миллиарде устройств, но в качестве системы контроля версий там сейчас, насколько мне известно, пользуются гитом. Хотя обе эти компании в свое время страдали NIH синдромом более, чем широко. Кстати, в качестве основных языков для разработки под Android выбрали сначала чужую Java, а затем чужой Kotlin.
lagudal
19.10.2019 10:13+12Перевод конечно вольный — я бы сказал, не просто вольный, а прям какая то адаптация сериала.
Оригинал
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. Земфира поет на вашем новогоднем корпоративе.
ProSev
19.10.2019 10:22+3нищебродских корейских иномарок
Корейский автопром корнями уходит в древние японские разработки. Так, к слову.
Но вот что интересно — корейские автомобили в Японии не продаются (по крайней мере официально).
rg_software
19.10.2019 12:08ProSev
19.10.2019 12:26Вот ссылка на видео, блогер в автотеме крутится и есть основания ему доверять.
rg_software
19.10.2019 15:53Спроса нет на самом деле. Купить можно, но это надо очень постараться. Они продавались раньше, но продажи были слабы.
squizduos
20.10.2019 17:03У Японии и Кореи исторически очень теплые взаимоотношения. Настолько теплые, что еще недавно действовали санкции на продажу продукции друг другу.
ilammy
19.10.2019 11:01+34Это всё равно на голову лучше типичного «перевода», из которого гроздьями торчат непричёсанные английские грамматические конструкции.
kinall
19.10.2019 11:05+8нищебродских корейских иномарок
В русском переводе «Американцев» тоже упоминается «корейский драндулет». Ну и если бы автор сохранил «японские машины», то перевод получился бы хоть и точный, но менее понятный – у нас в стране японские и немецкие машины примерно равны по статусу.
И с Земфирой тоже метко: мало ли кто там что где продаёт, это у нас абсолютно не показатель. А Земфиру все знают)ProSev
19.10.2019 11:47в оригинале герой Алика Болдуина на самом деле про конкретную корейскую марку автомобиля говорит, которая сейчас очень распространена у нас и её название начинается, пардон, с буквы «Х» (ссылка на фрагмент в первоисточнике). А то, что перевод обобщили и всех «корейцев» подстригли — так это, возможно, по соображениям этики (ну или ещё чего).
lagudal
19.10.2019 13:02+3Наверное, из-за того что я не был в Японии, мне представляется с трудом, что для среднестатистического японца в его технологически развитой Японии другой среднестатистический японец, обладающий японским автомобилем ассоциируется как нищеброд.
Пс. просто вообще не люблю это слово, которое очень любят применять те, у кого вот только что появилось 5 золотых в кармане, и теперь все, у кого в кармане меньше, для них нищеброды.
Koneru
19.10.2019 12:13+6Читал, не заметив плашку перевод, и до этого комментария не знал, что не оригинал, так что, прекрасная работа.
Baikov_Aleksandr
19.10.2019 10:22+9День добрый. Думаю, добавляйте смело пункт:
Найм на работу соседа по дому, любовниц, сына маминой подруги, человека который поможет устроить ребенка в садик и тд. Выше описанное, мне знакомо. Еще добивают люди, которые прошли мини курсы (за три дня) и используют слова (тебе в арсенал: каскадирование, кластеризация, гемба, краудсорсинг, управление развитием, лидеры перемен и многое другое.
engine9
21.10.2019 17:40А еще их мнение учитывается начальством наравне с программистским при решении, например, чисто технических вопросов.
jenki
21.10.2019 22:16А еще их мнение учитывается начальством наравне с программистским при решении, например, чисто технических вопросов.
Даже больше — в основном их мнение учитывается при решении специфических вопросов (имеющих опеределённую специфику: технические, экономические, ...)
DoctorZlo1981
19.10.2019 10:22+14Есть отличный совет — проводить совещания стоя. Сокращает время, проведённое на них, в разы.
0xd34df00d
19.10.2019 16:07+4На моей прошлой работе лид одной команды внял этому совету, и у него на дейли стэндапах все стояли. Правда, стэндапы все равно занимали иногда и час-полтора, так как стояли все, кроме него.
Выглядело это очень смешно.
Areso
19.10.2019 16:28+2Leader vs Boss.jpg
0xd34df00d
19.10.2019 20:13А, да, там ещё перед тем, как стать тимлидом, нужно было прослушать курс с названием «Path to leadership».
lanseg
19.10.2019 20:53+5На второй картинке лошадь, которая работала больше всех, но так и не стала председателем.
puyol_dev2
19.10.2019 10:44Мечта всех эффективных менеджеров — нанять рабов на галеры. И так будет всегда пока есть эффективные
AkshinM
19.10.2019 11:10+3А что на счёт бюрократии? За каждую мелочь все посылают писать заявку в соответствующей системе или эмайл с получением кучей не нужных "ок"-ов
mSnus
19.10.2019 11:12+1По-русски это называется "бронзоветь". Причем у нас этот процесс часто сопровождается ещё такими атавизмами, как, например, пение сотрудниками гимна компании, печати медалей "за заслуги перед компанией". До парикмахерской для собачек нам ещё далеко...
Gryphon88
19.10.2019 11:47+16В чём суть претензии? На старте компании руководство хотело денег и купаться в пафосе. Вы сосредоточенно и с полной отдаче работали, и теперь у них всё это есть, и они этим наслаждаются. Mission accomplished!
sshikov
19.10.2019 12:02+3>Настаивайте чтобы менеджеры нанимали лучших менеджеров чем они сами:
>Например тимлид должен нанять программиста, лучшего чем она, уж точно не хуже.
Взяли вот так с ходу и смешали менеджеров и программистов в одну кучу.
Кроме того, в моем мире программистов вообще — как грязи, а вот хороших — явный дефицит. И я охотно допускаю, что среди менеджеров ситуация похожая. Ну и где вы возьмете «лучшего чем я», если их на рынке мало?
А главное — кто это «лучше чем» будет оценивать?
Viceroyalty
19.10.2019 18:34С любыми специалистами так
sshikov
19.10.2019 19:28Ну вообще наверное да, с любыми. Ну и потом, как ниже резонно написали, кто их будет оплачивать, самых лучших? Я уже не говорю о том, чем вообще их заманивать.
Viceroyalty
19.10.2019 21:26Тут вопрос — что вам нужно, специалист как и техника должен быть достаточен для решения вашей задачи. Если менеджмент не знает кто им нужен это проблема в любом случае
DmitrySpb79
19.10.2019 12:29+10По-моему, описанное в статье типично для компании, где ИТ не является приоритетным. Ну а то, что начальство ездит по международным командировкам, а сотрудники пашут 8-часовой рабочий день — это нормально, just business. Только новичок может завидовать тому, что у начальства или менеджмента машины лучше, особенно если этот новичок никогда не пробовал открыть никакого дела сам.
Но если на корпоративе компании поет Земфира, а сотрудники не могут 100$ на новый SSD-диск у руководства выбить (лично видел как некоторые покупали себе в офис стул или монитор получше за свой счет в довольно крупной компании), то да, это звоночек что возможно есть места и получше :)
С другой стороны, главная добродетель начальства — не мешать работе. Так что пусть что угодно на корпоративах делают, если задачи интересные и зарплата платится вовремя, то и бог с ними.Viceroyalty
19.10.2019 18:35И обычно у начальства или менеджмента машины и квартиры явно не соответствуют зарплатам
Paskin
20.10.2019 07:57Командировки тоже бывают разные. С точки зрения «сотрудников» — «а, вы там наверное по пляжам шлялись и стейки хомячили». С точки зрения CEO и CTO — «весь полет вносили правки в презентацию, ночью фигачили почти 400 км на машине. Потенциальные клиенты — тоже не дураки, стараются минимизировать свои обязательства и максимизировать наши. Потом еще встреча — в другом городе. А оттуда нужно еще вернуться, сдать машину и первый раз за трое суток нормально (сидя) пожрать».
DmitrySpb79
20.10.2019 10:00+1Согласен.
Вообще, и красивый офис, и сотрудник ведущий корпоративный блог, и поездки руководства по миру и прочее — это как раз та менеджерская работа, которая и обеспечивает рядовым сотрудникам приток новых заказчиков и стабильную зарплату.
Ну а жаловаться что у начальника машина дороже, вообще глупо — открой свое дело, стань начальником и заведи такую же, какие проблемы :) То что у начальника и рисков в разы больше, и в нормальных компаниях работают они зачастую побольше подчиненных, многие не замечают.
Конечно, есть и фирмы где тупо пилят бюджет, и на которые законы рынка не действуют, тут другой вопрос.
un1t
19.10.2019 12:30+7Например тимлид должен нанять программиста, лучшего чем она, уж точно не хуже.
Т.е. мидлы компании совсем не нужны и джуны, одни сеньоры? А если нанимать программиста круче чем лид, то ведь и денег надо ему больше платить. Как-то это совсем странно выглядит.
А кто будет выполнять тупые задачи типа формирование очередного отчета для бухгалтерии или интеграция со 100500м API? Сеньоры это могут делать, но это слишком скучно и будет их демотивировать (или мотивировать свалить отсюда подальше), а джунам это в радость.
HEKET313
20.10.2019 16:42Смотря какую задачу в данной компании выполняет тимлид. Если тимлид = ведущий разработчик, тогда да, Ваш комментарий релевантен. Но есть компании, где тимлид — менеджерская позиция, где у тимлида 5-7 разрабов в подчинении и его обязанности: дейли провести, таски в спринт накидать, плэннинг провести, с продактом задачки обсудить, на митинги с руководством ходить и в принципе заниматься управлением. И дай бог останется у такого тимлида 2-3 часа в неделю на кодинг. И вот в этом случае найм разработчика выше уровнем, чем сам тимлид — вполне себе нормальная практика. Да и потом не каждый синьор горит заниматься менеджерской работой, так что тут никаких противоречий.
un1t
22.10.2019 13:49Хм, если человек не занимается кодингом, то я бы не называл эту позицию тимлидом, просто менеджером. Хотя верю, что в разных компаниях своя терминология. А менеджеру не обязательны технические скилы, он может вовсе не уметь программировать. Тогда любой программист будет лучше чем он, даже самый посредственный. Т.е. сравнивать гуманитария менеджера с программистом вообще непонятно как.
Myxer
22.10.2019 10:58+1Я может быть ошибаюсь, но всегда считал, что "хороший" и "опытный" это понятия, конечно, кореллирующие, но не синонимы. Может быть хороший тимлид и плохой тимлид, так же может быть хороший толковый джун, который когда-то вырастет в мидла или дальше, и плохой джун… И это в общем то относится, наверное, к любой профессии.
Думаю имелось ввиду, что надо нанимать хороших джунов, хороших мидлов и т.п. а не то, что надо брать одних тимлидов…
Barma2012
19.10.2019 13:10+5Объясните пожалуйста, почему каждая вторая компания высасывает из пальца какую-то «миссию»? Для чего нужны эти пафосные и лицемерные фразы?
ИМХО, единственная настоящая миссия у коммерческой компании только одна — заработать денег. Всё. Только для этого она и создавалась — вне зависимости от того, осознавалось это владельцами, или нет.vladshulkevich
19.10.2019 13:23они боятся формулировать, надо зашифровать. вместо декларации «мы хотим заработать денег»
Kanut
19.10.2019 13:47+3Деньги можно тоже по разному зарабатывать. И одно дело если вы например помогаете людям решать проблемы и зарабатываете на этом деньги. И совсем другое дело если зарабатываете деньги тем что создаёте людям проблемы.
И да, назначение какой-то "миссии" стало в последнее время очень модным и это делают все кому не лень. Но это совсем не означает что вообще нет фирм созданных "вокруг" какой-то "миссии" или "идеи".
Areso
19.10.2019 14:59+10Адвокат надеется, что у вас неприятности,
доктор надеется, что вы заболели,
полиция надеется, что вы станете преступником,
учитель надеется, что вы невежественны,
производитель гробов хочет, чтобы вы умерли,
и только инженер желает вам процветания в жизни,
чтобы он мог построить ваш дом, облагородить и обставить его, чтобы вы могли жить и наслаждаться долгой здоровой жизнью.
Пожалуйста, обними инженера рядом с тобой,
Он твой единственный верный друг.
Windalex
19.10.2019 17:10+3Понимаю, что юмор, но категорически не нравится. Не все врачи огорчатся от внезапного всеобщего здоровья, не все правоохранители расстроятся от отсутствия преступности. И т.д.
А вдруг тот самый Толькоинженер хочет построить Вам дом так, чтобы как можно скорее пришлось строить новый дом?trueMoRoZ
20.10.2019 00:09в больницах есть нормы по больным. врачам платят за больных, а не за здоровых. как-то так
Kanut
20.10.2019 00:15+1Так и инженерам обычно платят за постройку нового дома, а не за то что старые дальше стоят.
Но к счастью несмотря на всё это, в мире полно и хороших честных врачей и хороших честных инженеров :)
Windalex
20.10.2019 07:38И пусть и тех и других будет больше!
Изначальный посыл видимо сводится к тому, что в случае всеобщего благополучия- врачу и полицейскому придётся менять профессию, а инженеру не придётся. Только как-то криво получилось, аморально. По другому бы выразить.
Лично знаю очень хороших врачей, профессионалов своего дела, любящих свою работу, которые с радостью сменили бы свою профессию в обмен на общее здоровье. Ещё и расценили бы это как новый опыт. В мире так много интересного. Всегда найдёшь, чему учиться и к чему приложить свои силы.
А пока -да, пусть будет больше хороших честных врачей, учителей и инженеров.
Viceroyalty
19.10.2019 18:37+1Можно сказать, что инженер надеется что ваш дом развалится чтобы построить новый
Londoner
19.10.2019 19:36+4Скорее так — инженер строит дом из специально разработанных материалов, перестающих служить на следующий день после окончания гарантийного срока.
KvanTTT
19.10.2019 14:13Во-первых, есть чисто благотворительные компании. Во-вторых, деньги — это инструмент, а в условиях капиталистической экономики — необходимый. А что делать, если денег достаточно и даже много? Как минимум расширять влияние, штат, инвестировать в более рисовые проекты. Так что нет, не все, не для этого она создавалась, если это конечно не чистый отмыв.
KvanTTT
19.10.2019 14:16+1Много программистов, которые открывают код просто так, не думая о монетизации (ну ок, о репутации, карьере может и думают). Скорее всего такие люди существуют не только среди программистов, но и бизнесменов.
shinsheel
19.10.2019 15:10+2Владельцы очень редко создают компанию только для заработка денег — 90% компаний просто прогорают не выйдя в плюс.
Хотя как раз слово «миссия» это из мира корпоративного буллшита, конечно, если речь идет не про НКО
1c80
19.10.2019 15:10+3Миссии, по их задумке это стимул, ведь согласитесь, что прямое знание того, что живешь и работаешь, что бы кто то другой жил все лучше и лучше используя плоды твоей работы, по определению не самый лучший стимул. Исключение лишь при полной прозрачности процессов,
когда каждый получает свою, за ранее оговоренную долю, пропорционально внесённому в общий процесс вкладу или типа того.KvanTTT
19.10.2019 15:37+2ведь согласитесь, что прямое знание того, что живешь и работаешь, что бы кто то другой жил все лучше и лучше используя плоды твоей работы, по определению не самый лучший стимул.
По-моему очень неплохой стимул. Когда кто-то интересуется твоим трудом, а тем более использует его — это, как минимум, приятно (говорю за себя, как программиста).
1c80
19.10.2019 21:16Ну тогда Ваша жизнь сплошное блаженство, не часто вижу, что бы кто то заказывал, а потом не использовал и в добавок абсолютно бы не интересовался, насколько быстро он сможет получить желаемое в лучшем виде, но все не так просто, гораздо правильнее ориентироваться на свое внутреннее состояние и здраво воспринимать адекватную критику, все остальное лишь манипуляции, слова людей обычно мало что значат, у каждого своя цель.
Хотя конечно выше, я малость погорячился в своём высказывании изначально миссия была задумана, как некий объединяющий фактор, который добавляет чуточку игры в рутину, но дело тонкое, чуть переборщил и вот всё уже превратилось в одну сплошную игру.khim
20.10.2019 02:18не часто вижу, что бы кто то заказывал, а потом не использовал и в добавок абсолютно бы не интересовался, насколько быстро он сможет получить желаемое в лучшем виде
Э нет. Не путайте «востребованность» и «кто-то пользуется твоим трудом» и «абсолютно бы не интересовался, насколько быстро он сможет получить желаемое в лучшем виде»
Огромное количество работ, исполняемых программистами — это разновидность армейского «хацю шоб слоники побегали».
То есть вымотать из программиста все нервы — это святое… А потом это поделие засунуть куда-нибудь и никак не использовать — это тоже сплошь и рядом.1c80
20.10.2019 09:52Ну таких за километр обхожу, у них и бабла-то нету никогда, а то что фича устарела пока делали или придумали что-то по лучше, вполне нормальное явление,
главное что бы время было оплачено.
Viceroyalty
19.10.2019 18:38-2Пирамида Маслоу это разговоры в пользу бедных
Viceroyalty
20.10.2019 01:31-1Ничего себе — ещё и карму в минус загнали. Хорошо, что карма существует только на хабре а не в жизни. Это я в к тому что компании расплачиваются данными принципами вместо части зарплаты
mSnus
19.10.2019 15:16+2Потому что когда люди работают за общую, объединяющую идею, им можно не платить за переработку.
Viceroyalty
20.10.2019 07:45-1Правильно говорите, смотрите чтобы вас как меня не слили
mSnus
20.10.2019 07:48+1Да я уже привык. Причём самое забавное, что плюсы ставят пока комментарии свежие, а вот минусы могут потом ещё долго прилетать :)
apapacy
19.10.2019 16:57Миссия как мне кажется изначально задумывалась не как пафос а как способ структурирования целей компании. Что то вроде главная цель. Или ответ на вопрос почему наши продукты или услуги будут нужны человечеству. В нашем исполнении я могу предположить что миссия превратилось во что то ты книге и пафосное.
ApeCoder
19.10.2019 22:14+2Чтобы сформулировать идею, каким образом в отличие от других компании собираются заработать денег.
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.
...
Киоск с шаурмой: Мы накормим Южное Бутово самой дешевой шаурмой с картошкой
Разумеется, если вы еще не заметили, то люди из всего делают карго культ.
un1t
19.10.2019 22:22Да просто карго культ.
ИМХО, единственная настоящая миссия у коммерческой компании только одна — заработать денег.
Есть небольшое число компаний, для которых важно не просто заработать бабло, но и сделать продукт хорошего качества. Такие компании грубо говоря не будут пихать пальмовое масло в печенье. И не будут на упаковке йогурта писать 110 грамм, когда там на самом деле 90, включая упаковку. А чтобы рядовые сотрудники понимали, что компания тут не ради бабла, а ради хорошего продукта можно сделать хорошую и понятную миссию-слоган. Если это единственная мера, то этого естественно не достаточно.
К сожалению таких компаний мало, а даже большинство тех которые изначально хотели делать хороший продукт, столкнувшись с конкурентами у которых сильно дешевле и обещания слаще, чтобы не обанкротиться вынуждены идти на компромиссы с совестью.
И тогда миссия становиться уже такой же фигней как «ну мы же команда».
Ну а у большинства компаний, миссия это вообще какая-то бессмысленная белиберда высосанная из пальца и нужна просто «чтобы было», потому что у нормальных пацанов есть, и у нас должно быть.
Durimar123
21.10.2019 15:28Есть небольшое число компаний, для которых важно не просто заработать бабло,
Можно назвать несколько таких компаний?un1t
21.10.2019 20:33Не ручаюсь, но по тому что описано в книге, например Patagonia (производство одежды и снаряжения).
Ну и еще мне кажется социальное предпринимательство тоже в эту сторону. Люди в первую очередь хотят решить какую-то социальную проблему.
DoctorZlo1981
19.10.2019 23:29+1Потому что в современном мире мотивация сотрудников основана не только на деньгах. И наличие какой-либо дополнительной цели будет радостно воспринято частью персонала. Человек, знаете ли, ищет смысл в своём существовании.
Gradiens
21.10.2019 11:21Миссия — штука полезная. Только не все умеют ее готовить.
Миссия — это маяк, на который должны ориентироваться сотрудники при принятии решений. Вот как пример миссия 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 лет работы так и не понял сути миссии текущего работодателя...
0xd34df00d
21.10.2019 16:01+1Только ведь ютуб тот еще цензор, и этой миссии он нифига не соответствует.
un1t
21.10.2019 20:25Проблемы конечно существуют, но это скорее не по воле ютюба, а потому что он действует в рамках законодательства и на него оказывают давление другие заинтересованные стороны — правительство, копирасты, т.п.
С некоторыми допущениями он вполне себе соответствует.
engine9
21.10.2019 17:43Удивитесь, но у некоторых людей идеальная (от слова идея) мотивация может быть основной, стоящей над денежной.
В это совсем невозможно поверить, человеку не обладающего такой мотивацией.un1t
21.10.2019 20:37Я думаю что все знаю таких людей, хотя бы теже учителя и врачи. Сомнения возникают на этапе того, что может ли такой человек стать предпринимателем и успешно управлять компанией в течении продолжительного времени, конкурируя с другими и не уронив при этом качество продукта.
genind
22.10.2019 10:55Объясните пожалуйста, почему все считают что цель любой компании «заработать денег»? ИМХО это не совсем так. Почти у каждой компании есть некоторые задачи и чтобы её выполнять приходится зарабатывать деньги. Сам по себе этот доход не имеет какого либо смысла, почти всегда средства нужны для какой либо текущих целей, расширение сети, pr проект, открытие завода и т.д. Конечно это все вопрос уровня курицы и яйца, но все же вот такие категоричные заявления сильно искажают восприятие.
По моему конечная цель любой компании — расширение и выживание. Т.е. по сути то же что и у любого живого существа в дикой природе, как ни странно. Т.е. говорить что цель компании доход — все равно что говорить что цель кролика — съесть всю траву, звучит странно.
Если подходить с этой точки, то становится более понятно почему важны те же кредиты и почему многие крупные компании из них никогда и не выходят, хотя они по сути уменьшают доход, но позволяют расширяться значительно быстрее.Kanut
22.10.2019 11:00Вы извините, но цель большинства частных компаний это именно заработать деньги. Просто иногда это "заработать здесь и сейчас", иногда "зарабатывать не определённом отрезке времени", а "иногда зарабатывать в идеале бесконечное время".
А ваши "текущие цели" это всего лишь инструмент для того чтобы увеличить отрезок времени на котором будут зарабтываться деньги и/или в увеличить количество денег, которое будет зарабатываться в будущем.
khim
22.10.2019 11:46По моему конечная цель любой компании — расширение и выживание.
Не совсем так.
Объясните пожалуйста, почему все считают что цель любой компании «заработать денег»?
Строго говоря цель любой компании — делать то, что скажут акционеры.
При этом в случае когда акционеры — это банкиры и владеют акциями не одной компании, а нескольких им может быть выгодно одну из компаний уничтожить, если акции других, при этом, вырастут. Сделать это с минимальными потерями — тоже исскусство.
Есть и совсем особые случаи, скажем в случае Гугла 50% акций находятся у «триумвирата» (Брин, Ларри, Шмидт) и они втроём могут договориться и решить делать что-то, что всем остальным акционерам не нравится никак (маловероятно, впрочем: если даже один из них сойдёт с ума вряд ли двое других безоговорочно их поддержат).
Am0ralist
22.10.2019 12:33Есть и совсем особые случаи, скажем в случае Гугла 50% акций находятся у «триумвирата» (Брин, Ларри, Шмидт) и они втроём могут договориться и решить делать что-то, что всем остальным акционерам не нравится никак (маловероятно, впрочем: если даже один из них сойдёт с ума вряд ли двое других безоговорочно их поддержат).
И на них подадут в суд за ущемление миноритариев, за что тем придётся компенсировать прочим потери, а может и выкупать акции, агаkhim
22.10.2019 13:41Это вряд ли. Про то, что структура акций устроена вот именно так и про то, что миноритарии не смогут с этим ничего поделать — написано ажно в заявке на IPO, в SEC поданной.
И этот подход весьма распространён в разных медиа-компаниях (всякие New Your Times и Desney), так что вряд ли суды будут склонны менять статус-кво.
Shotgun12G
22.10.2019 10:55«мы хотим заработать денег» — это отражается в типе компании (коммерческая\не коммерческая).
Миссия компании — это своеобразное лекало, которое можно приложить к сомнительной ситуации и принять решение.
Ну например: есть оборудование, обладающее некоторыми, пусть выдающимися, характеристиками, но построенное на сырой технологии. Можно ли его продать?
И если вы торговая площадка, миссия которой «продать хоть черта лысого» — однозначно да.
Если вы производитель оборудования, который «делает надежное оборудование» — однозначно нет.
Singaporian
19.10.2019 14:17+1Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю
- Если в компании повышение званий/статусов происходит чаще повышения зарплаты — первый признак, что зарплату начали выдавать "лычками" — это устраивает только серых людей.
- Если на протяжении длительного периода, например месяца, не было ни одного принятого в работу предложения уменьшения тех.долга (да не только тех — любого долга).
- Ну и самое королевское: когда в компании есть DevOps-отдел.
KvanTTT
19.10.2019 14:39+3А с последним что не так?
Kanut
19.10.2019 14:49+4По идее DevOps подразумевает под собой что "dev" и "ops" работают вместе в одной команде.
dominigato Автор
19.10.2019 14:58Ну вообще-то не в одной команде. А между их командами есть хорошая и гладкая коммуникация, которую и обеспечивают DevOps инженеры.
Singaporian
19.10.2019 14:50Потому, что DevOps — культура взаимной ответственности dev'ов и ops'ов, когда они сами разгребают свое дерьмо. Когда вы снимаете ответственность с dev'ов и ops'ов и перекладываете на какой-то третий отдел, то DevOps на этом заканчивается по определению. А вместо него начинается бесконечно разрастающаяся автоматизация костылей, что и есть тема сегодняшнего диалога — "одебиливание".
Вообще, ящетаю, отдел DevOps — это уже последняя стадия лицемерия.
Barabek
19.10.2019 14:55+4С компанией становится все понятно, когда в ней заводятся коучинг, менторинг, наставничество, миссии, тренинги по управлению эффективностью и т.п. Незаметно вдруг вы замечаете, что 30% времени ваши сотрудники тратят на чтение рассылок с новостями HR, просмотр презентаций о миссиях, корпоративной культуре, участвуют в каких-то конкурсах, номинациях, тестах и прочей лабуде. А на деле оказывается, что HR не способен банально не может подобрать вам кандидатов, потому, чти у них у самих текучка и все, что могут предложить — разместить вакансию на hh и насыпать вам откликов.
tmin10
19.10.2019 15:50+3Что не так с менторингом? Когда более опытный сотрудник помогает менее опытным в решении учебных и рабочих целей это же хорошо.
kantocoder
19.10.2019 14:56+1>Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю
Компания практикует такие методики управления проектами, как аджайл и скрам. (аджайл является убийцей бизнеса хотя бы потому, что напрямую способствует росту технического долга)Gryphon88
19.10.2019 15:16+1Хуже, когда вешают доску и говорят: У нас теперь аджайл! В остальном при этом ничего не меняется, остаётся в лучшем случае водопад.
kantocoder
19.10.2019 17:47+1Ну так хорошо, если водопад остается. Вполне работающая методика.
Viceroyalty
19.10.2019 18:40Для ресурсоемких и наукоемких разработок как раз нужен водопад
kantocoder
19.10.2019 19:01Пожалуй что так, согласен. Собственно, везде, где есть стратегическое планирование, аджайл не подходит, он не для этого создавался.
Viceroyalty
19.10.2019 19:09Хорошо бы чтобы практики и методологии читали как инструкцию к лекарству — сначала показания к применению
Gryphon88
19.10.2019 21:41Когда есть полные и (почти) неизменные техтребования и понятный протокол тестирования, то водопад или V-модель самое то. Но под новой вывеской придётся ещё торчать у доски, на ежедневных пятнадцатимитках, где говорит «за вчера я не закончил ни один модуль целиков», а если особо повезёт, то ещё играть в «покер планирования» с высокими ставками.
kantocoder
19.10.2019 22:13Вот тут похожее рассказывают: https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#6c7bccc42071
Gryphon88
19.10.2019 22:19Просто гибкие методологии стали пихать куда попало, или просто этикетку переклеивать. Если делать что-то небольшое, на повремянке и без окончательного понимая заказчиком, а чего он, собственно, хочет — гибкие методологии самое то. MVP, короткие итерации, стейкхолдер/ПО прям в команде… А поскольку таких экспериментаторов несколько, то тут и «flexible commands» в тему: ну не нужен сейчас, например, дизайнер, ну он и ушёл.
Kanut
19.10.2019 15:20+3Извините, но вот тут не соглашусь. Аджайл и скрам сами по себе не являются ни убийцами бизнеса, ни ведут к повышению технического долга.
Я бы даже сказал что если это действительно аджайл и скрам, то они скорее улучшают ситуацию в этом плане.
Другое дело что часто вводят какие-то неадекватные процессы и их почему-то называют "аджайл" и "скрам". И вот это скорее признак "одебиливания".
apapacy
19.10.2019 17:10Про модные методики из глянцевых журналов чтобы понять приносят они эффект или не приносят эффект необходимы такие предпосылки.
- Наличие собственно определенных принципов на которых строится методика отличных от других методик. Например в одной из методик говорится что главным является тесное взаимодействие между людьми участвующими в разработке. Где тут научная новизна?
- Наличие связи между принципами и собственно методиками чтобы можно было сказать что этот пункт методики соответствует какому тот принципу. Зачастую можно наблюдать что предлагаемые частные методики с натяжкой связаны с исходными принципами которые были озвучены в манифесте.
- Критерии по которым можно доказать что компания следует или не следует принципам и методикам.
Критерий как я понимаю один. Если компания успешная значит она правильно следует методике. А если компания неспешная стало быть она неправильно следует методике. Или выбрала неправильного коуча. Но таким способом можно доказать эффективность любой методики.
Kanut
19.10.2019 17:22+1У большинства "модных методик" описаны правила которым надо следовать. Обычно они описаны достаточно чётко. Как минимум в случае скрама это так.
Если этим правилам не следовать, то вы уже однозначно неправильно следуете методике или по хорошему вообще ей не следуете.
П.С. Ну и я на своём личном опыте уже успел почувствовать что происходит когда фирма переходит на скрам и следует правилам. И что происходит когда фирма просто говорит что переходит на скрам и при этом придумывает какие свои "с(к)рамоподобные" правила и процессы.
kantocoder
19.10.2019 17:58Ну и я на своём личном опыте уже успел почувствовать что происходит когда фирма переходит на скрам и следует правилам. И что происходит когда фирма просто говорит что переходит на скрам и при этом придумывает какие свои "с(к)рамоподобные" правила и процессы.
Не сочтите за труд, расскажите, интересно все-таки
Kanut
19.10.2019 18:13Ну "неправильный скрам" был немного похож на то что вы описали выше. То есть разбили всех на команды и заставили устраивать скрам-митинги. Но при этом в каждой команде всё решал исключительно ПО(которых набрали из бывших менеджеров и начальников отделов)
В "нормальном скраме" у нас бэклог, который мы потихоньку отрабатываем. Веши вроде документации и автоматизированных тестов включены нами в DoD и без них обычно ничего не релизится.
Исключения конечно тоже бывают, но разрешено всё это "отодвинуть" максимум на один спринт и только если все согласны.
Это если коротко и про техдолг.
kantocoder
19.10.2019 18:39Похоже, вы решили обойти скрам и делать все по-человечески. Если бы вы еще и от скрам-митингов отказались, а делали бы все согласно ТЗ, то это был бы не скрам, а водопад.
Scrum означает толкучка, в которой весь коллектив решает что нужно сделать и когда. Т.е. нет стратегического планирования, нет четких сроков поставки продукта и т.д.
Про backlog тоже интересное наблюдал: взял сотрудник (не я) задачу из бэклога, поковырял ее, поковырял, не получилось, и он обратно ее в бэклог запихал (он сам на митинге об этом рассказал). У меня от удивления глаза на лоб полезли:
Гениального философа… Величайшего программиста современности… И запрячь в тяжеленную машинунедоделанную задачу запихать обратно туда откуда взял?! Что за хрень?!?!
Помимо вышеописанного, на мой взгляд система, в которой люди работают не по плану, а по приоритетам, слишком гибкая. Она также плоха для разработчика — четкий список задачь с конкретным дэдлайном хоть и заставляет ответственно относится к работе и уметь оценивать своё время разработки, но он также и защищает от сверхэксплуатации со стороны работодателя. А не так, что "эта фича должна быть сделана еще 3 месяца назад, поэтому ее нужно сделать как можно скорее. Даём тебе 2 дня.".
Список задач — это контракт между тобой, и твоим непосредственным начальником, что написано — то и делаю. Не написано — не делаю.
Kanut
19.10.2019 19:01+2Похоже, вы решили обойти скрам и делать все по-человечески.
Мы ничего не обходили и делаем тот самый банальный скрам. Ну или как минимум что-то с нашей точки зрения максимально к нему приближённое.
Если бы вы еще и от скрам-митингов отказались, а делали бы все согласно ТЗ, то это был бы не скрам, а водопад.
Мне интересно как вы пришли к такому выводу. На мой взгляд именно митинги не делают разницы между скрамом и водопадом. И как раз одна из распространённых ошибок это добавить в водопад скрам-митинги и считать что ты теперь делаешь скрам :)
Scrum означает толкучка, в которой весь коллектив решает что нужно сделать и когда. Т.е. нет стратегического планирования, нет четких сроков поставки продукта и т.д.
Это абсолютно не так. Команда решает как конкретно реализуется та или иная фича из бэклога. Какие фичи добавляются в бэклог и в каком порядке их делать, решают ПО и клиент в лице стэкхолдера.
"Стратегическое планирование" от этого не будет хуже чем в том же водопаде. Зато наоборот есть возможность относительно быстро среагировать если вдруг что-то пошло не так или клиент решит что он хочет идти в другом направлении.
Про backlog тоже интересное наблюдал: взял сотрудник (не я) задачу из бэклога, поковырял ее, поковырял, не получилось, и он обратно ее в бэклог запихал
Опять же это не скрам. Что берётся из бэклога на следующий спринт решает вся команда. И этим она обязуется сделать это до конца спринта. "Запихать" что-то обратно в бэклог можно только если спринт отменяется целиком и это очень редкое явление и я не припомню ни разу чтобы у нас это инициировала команда.
Она также плоха для разработчика — четкий список задачь с конкретным дэдлайном хоть и заставляет ответственно относится к работе и уметь оценивать своё время разработки, но он также и защищает от сверхэксплуатации со стороны работодателя
В скраме есть чёткий список задач с дедлайном. Просто дедлайн это конец спринта, а список задач на спринт составляет сама команда.
И когда спринт начался, то в список задач можно что-то добавить только если уверены что успеваете и все имеющиеся задачи будут закончены до конца спринта. И если с этим согласна вся команда.
П.С. Вы извините конечно, но по тому что вы пишите я вижу что вы не особо то и понимаете что такое скрам и как он должен работать.
kantocoder
19.10.2019 19:10-1"Стратегическое планирование" от этого не будет хуже чем в том же водопаде. Зато наоборот есть возможность относительно быстро среагировать если вдруг что-то пошло не так или клиент решит что он хочет идти в другом направлении.
Вот! Я же говорю, что скрам слишком гибок — прогибается под клиента. Я это тоже уже проходил — компания, в которой я работал, тоже прогибалась под клиента, а тот постоянно менял ТЗ. Кончилось это вот чем: более миллиона у.е. долга для самой компании, реструктуризацией, и поглощением материнской компанией. Деньги потом все же выбили, через суд.
Kanut
19.10.2019 19:19+1Вот! Я же говорю, что скрам слишком гибок — прогибается под клиента.
Что в вашем понимании означает "прогибается"? Это же не так что "изменения направления" делаются за счёт фирмы-исполнителя. Если нужны глобальные изменения, которые сильно отличаются от изначального ТЗ, то это всё обычно делается за дополнительные деньги.
Или грубо говоря есть бюджет и если есть изменения, то все они делаются пока бюджет не исчерпан.
Другое дело что для клиента это обычно всё равно выгоднее чем получить в результате "неправильный продукт" из-за неправильного ТЗ.
kantocoder
19.10.2019 21:01-1Что в вашем понимании означает "прогибается"? Это же не так что "изменения направления" делаются за счёт фирмы-исполнителя. Если нужны глобальные изменения, которые сильно отличаются от изначального ТЗ, то это всё обычно делается за дополнительные деньги. Или грубо говоря есть бюджет и если есть изменения, то все они делаются пока бюджет не исчерпан.
Это даже не разработка, это CAM — Computer Aided Masturbation. Но если подходить с тем, что цель — тянуть деньги из клиента, то почему бы и нет? Но я все же надеюсь, что ракеты наши (одна из немногих вещей, которые у нас остались после ликвидации СССР Горбачевым) никогда не будут разрабатываться по аджайл.
Другое дело что для клиента это обычно всё равно выгоднее чем получить в результате "неправильный продукт" из-за неправильного ТЗ.
Зато думаю что если ТЗ правильное, то водопад будет выгодней. Потому что тщательное продуманное планирование позволяет не делать лишнего и не метаться из стороны в сторону под хотелки заказчика.
Kanut
19.10.2019 21:30Это даже не разработка, это CAM — Computer Aided Masturbation. Но если подходить с тем, что цель — тянуть деньги из клиента, то почему бы и нет?
Как интересно получается. Меня ситуация более чем устраивает. Моих коллег похоже тоже, иначе бы они наверное давно бы уже поувольнялись. Начальство вроде тоже довольно, иначе бы оно давно всё поменяло.
Клиентов тоже похоже всё устраивает, иначе бы они давно бы нашли себе кого-то другого.
Недовольны похоже только вы. Причём мне даже как-то странно и непонятно чем именно вы недовольны....
Зато думаю что если ТЗ правильное, то водопад будет выгодней. Потому что тщательное продуманное планирование позволяет не делать лишнего и не метаться из стороны в сторону под хотелки заказчика.
Во первых "правильное ТЗ" это на мой взгляд даже более редкое явление чем "правильный аджайл".
А во вторых некоторые проекты идут 3-5-10 лет. А наверняка и дольше бывают.
И у нас сейчас так быстро меняются обстоятельства что написать ТЗ на столько лет вперёд это практически невероятно.
Одни изменения законов чего стоят. Или изменения в трендах. Или появления новых технологий.
И этот список можно продолжать очень долго.
vdshat
21.10.2019 07:51Что ж это за «стратегическое планирование», при котором нужно быстро менять направление?! Это показатель как раз того, что заказчик не делал стратегического планирования: не изучал рынок, не прикидывал стоимость и т.д. А потом «внезапно» оказалось что, то что было «киллер фичей» оказывается уже кто-то делал и она уже умерла пару лет назад.
Kanut
21.10.2019 08:14Самое обычное планирование. Потому что если например планируешь на 3-5 лет вперёд, то абсолютно не всегда ясно как себя будут вести и что напридумают за это время конкуренты.
И тренды сейчас на 5 лет вперёд можно только ванговать. Да и изменения в законах пожалуй тоже.
Viceroyalty
19.10.2019 18:43Раз вы уже ответили — возвращаю коммент:
У аджила и скрама есть описание когда они помогут и когда они НЕ помогут, а помешают?
Если нет — их трудно воспринимать серьезноkantocoder
19.10.2019 18:55+1Нет. Вот их принципы: https://agilemanifesto.org/principles.html, часть из которых просто ложные утверждения, например вот это: "The best architectures, requirements, and designs
emerge from self-organizing teams"
kantocoder
19.10.2019 17:36-2Я бы ничего не говорил о аджайл и скрам, если бы сам с ними не столкнулся. Но увы, стартап в котором я трудился пользовался аджайл со скрамом и
шлюхамиджирой, накопил чудовищный техдолг, который я пытался разгрести, но меня не поняли и на том мы с ними и расстались.
Установка была такая: техдолг разгребать сейчас не время, а надо быстро-быстро прилепить еще фичу, чтобы заказчик продолжил финансировать проект. Штука в том, что на разгребание техдолга НИКОГДА нет времени, а потом все либо падает, либо приходит в состояние, в котором дальнейшее развитие просто невозможно.
Думаю, что стартап этот уже мертв — техдолг они врядли преодолели, а деньги их скорее всего уже закончились.
Один из краеугольных камней аджайла это "работающее ПО важнее исчерпывающей документации", т.е. присутствует прямая установка на создание техдолга. Техдолг смертелен для IT бизнеса. Значит, аджайл следует избегать at all cost, если хочешь выжить как компания.
Kanut
19.10.2019 18:00+2В том то и дело что то, что вы описываете, это не скрам. В скраме девтим решает каким образом делается фича, когда она считается готовой и сколько это займёт времени. И если кто-то со стороны приказывает девтиму что и как надо делать, то это уже не скрам.
А если у вас весь девтим решил наплевать на техдолг, то у вас не со скрамом проблемы, а с девтимом.
П.С. И "работающее ПО важнее исчерпывающей документации" никоим образом не означает что документация вообще не важна. Да и техдолг это не только документация.
kantocoder
19.10.2019 18:48-2Да и техдолг это не только документация.
Верно, техдолг это еще и отсутствие хорошо продуманной архитектуры. А чтобы архитектура была хорошо продуманна, нужно иметь представление о конечном продукте, и о возможностях развития продукта в долгосрочной перспективе. Т.е. необходимо стратегическое планирование.
А аджайл вообще не про это — аджайл про то, как эффективней прогнутся под заказчика и выполнить его хотелки, и тем самым обойти конкурентов.
Отсюда делаю вывод — аджайл скорее всего используется в потогонках (они же бодишопы, они же черные компании), которые либо консалтинге, либо оутстаффинге. Если компания разрабатывает свой продукт, аджайл для нее противопоказан.
Kanut
19.10.2019 19:11+1А чтобы архитектура была хорошо продуманна, нужно иметь представление о конечном продукте, и о возможностях развития продукта в долгосрочной перспективе. Т.е. необходимо стратегическое планирование.
У вас в скраме точно так же есть представление и о конечном продукте и о возможностях развития в долгосрочной перспективе.
И стратегическое планирование там тоже никто не отменял. Оно просто в некотором роде находится "уровнем выше" скрама. То есть вы выбираете ваши стратегические цели(например в виде milestone), а потом двигаетесь к ним при помощи скрама.
А аджайл вообще не про это — аджайл про то, как эффективней прогнутся под заказчика и выполнить его хотелки, и тем самым обойти конкурентов.
Аджайл это в первую очередь про то, как быстро понять что двигаешься в неправильном направлении и суметь сразу скорректировать курс.
Отсюда делаю вывод — аджайл скорее всего используется в потогонках (они же бодишопы, они же черные компании), которые либо консалтинге, либо оутстаффинге. Если компания разрабатывает свой продукт, аджайл для нее противопоказан.
Я знаю приличное количество фирм которые без особых проблем делают свой продукт и используют аджайл. Так что не сказал бы что ваш вывод так уж и правилен.
kantocoder
19.10.2019 20:32+4Аджайл в первую очередь то, что написано в его манифесте. А написано вот что, из Манифеста:
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.
Это просто чушь. Лучшие архитектуры, требования, и дизайны возникают из большого опыта разработки, и тщательного, хорошо продуманного планирования.
Я знаю приличное количество фирм которые без особых проблем делают свой продукт и используют аджайл. Так что не сказал бы что ваш вывод так уж и правилен.
Отлично, приведите несколько примеров этих фирм и какой продукт они производят. Мне очень любопытны отзывы о качестве продукта, как и отзывы сотрудников о работе в этих компаниях (хотя последнее вторично).
Я вполне допускаю что умные люди "подкрутили" аджайл так, чтобы это по-факту был водопад в обличии аджайл (дабы угодить руководству). Но и мой личный опыт, и сам манифест, и даже уже и сами создатели аджайла (если интересно, пришлю ссылку), говорят о вреде аджайл.
Kanut
19.10.2019 21:09Два первых пункта напрямую приводят к возникновению техдолга.
Не вижу почему это обязательно должно так происходить. Более того я знаю кучу примеров когда этого не происходит. В том числе и у нас на фирме. Что мы делаем не так?
Как я уже и писал, аджайл нужен для того, чтобы оттеснить конкурентов через постоянных прогиб перед заказчиком
От того что вы это написали оно не становится истиной.
Это просто чушь. Лучшие архитектуры, требования, и дизайны возникают из большого опыта разработки, и тщательного, хорошо продуманного планирования.
Этот пункт скорее о том что вы можете быть гениальным софтвар-архитектом, но если у вас начальник дурак и он имеет абсолютную власть и принимает решения, то нормальной архитектуры у вас не будет.
Отлично, приведите несколько примеров этих фирм и какой продукт они производят.
Сомневаюсь что названия фирм вам что-то скажут, но если прямо хотите, то могу скинуть в личку.
Я вполне допускаю что умные люди "подкрутили" аджайл так, чтобы это по-факту был водопад в обличии аджайл (дабы угодить руководству)
Как раз таки чтобы аджайл работал, первым к этому должно быть готово руководство. И не только на словах.
И мне теперь стало интересно что вы вообще вкладываете в понятие "водопад".
Но и мой личный опыт, и сам манифест, и даже уже и сами создатели аджайла (если интересно, пришлю ссылку), говорят о вреде аджайл.
Ваш личный опыт, ну или как минимум то, что вы рассказали здесь, говорит мне о том что вы аджайл как таковой и не видели. Скрам уж точно.
А ссылку можете прислать, интересно будет посмотреть.
kantocoder
19.10.2019 21:26+1Вот статья от одного из авторов аджайл о том, что пора бросить аджайл: 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
Надеюсь что пришлете в личку названия компаний практикующих аджайл, интересно что они производят и какой у них технологический стэк (думаю что это веб-технологии)
Kanut
19.10.2019 21:39Вы мне эти ссылки просто по быстрому нагуглили или сами их хотя бы прочитали? :)
Там же сразу идёт ссылка на:
1Here 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.
kantocoder
19.10.2019 21:49+2Парочку я давно уже читал, когда еще работал в том стартапе, чтобы выяснить что это за диковинный зверь такой — аджайл, которого активно разводят в России (весь мой корпоративный опыт — не российский). И откуда растут такие дивные уши техдолга. А пока искал их, нашел еще статьи, они тоже годные как вижу. Как видно, многие разработчики не переносят аджайл, как и я.
Kanut
19.10.2019 21:54Ну, как я уже писал выше, по моему опыту разработчики, которые не любят аджайл, на самом деле никакого аджайл никогда и не видели и на самом деле не любят тот самый "так называемый аджайл" о котором пишет в приведённой вами статье Рон Джеффри.
И вы на мой взгляд являетесь ещё одним подтверждением этого правила :)
kantocoder
19.10.2019 22:02+2Смотрите, весь мой корпоративный опыт разработки описывается вот этим:
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
мне вообще не понятны, это просто хаос.Kanut
19.10.2019 22:14+2Смотрите, весь мой корпоративный опыт разработки описывается вот этим:
Если для вас и ваших клиентов это работает, то это замечательно и вам аджайл не нужен. Но это не значит что аджайл сам по себе что-то плохое.
Поэтому такие вот выкрутасы:
?Flexible, cross-functional team composition
?Collaborative and interactive approach to requirements
мне вообще не понятны, это просто хаос.А мне вот отлично понятны и у нас великолепно работают:)
Первое это про то что если ты умеешь больше чем что-то одно, то ты можешь делать больше чем что-то одно. Главное чтобы в команде все необходимые роли были заняты и желательно ещё и продублированы. Ну и чтобы при необходимости человека можно было заменить.
А второе это о том, что к разработке "requirements" в том или ином виде привлекают команду.
То есть грубо говоря requirements определяют не только менеджеры с клиентом, но в том числе и разработчики которым это потом реализовывать.Gryphon88
19.10.2019 22:21Не путайте техтребования (описание продукта в терминах предметной области, составляется клиентом и менеджерами) и спецификации (составляются тимлидом/архитектором в терминах разработки и программирования).
Kanut
19.10.2019 22:54Ну у нас разработчиков(как минимум сениоров/техлидов/архитектов) и местами UI/UX дизайнеров привлекают и туда и туда. Правда митинги с клиентом у нас это добровольно и можно если не хочешь, то не присутствовать.
Как в других фирмах это делается я не особо спрашивал и не то чтобы в курсе. Может быть и мы это делаем не по канону :)
Gryphon88
19.10.2019 23:00Вообще да, не по канону :) Не, присутствовать может кто угодно, но про программирование говорить нельзя, чтобы заказчика не смущать. Задача-то в том, чтобы разобраться, как оно должно работать, разработать критерии приёмки и тестирования, краевые случаи применения… Т.е. внешнюю, доступную юзеру часть и условия с процессом эксплуатации.
Kanut
19.10.2019 23:14Ну что значит "про программирование" и "заказчика смущать". У нас на счастье заказчики обычно хоть немного но тоже в теме.
Ну и кроме того им алгоритмы никто на бумажке не рисует. Просто обычно это вещи вроде "так будет дорого и/или долго, а вот так быстрее и/или дешевле".
Ну и я лично большую часть времени просто сижу и слушаю, а в паузах подкидываю идеи нашим менеджерам. Ну и на технические вопросы отвечаю если они возникают.
П.С. Хотя это тоже сильно от клиентов зависит. К некоторым я вообще не хожу так как мне нервы дороже. А некоторые наоборот предпочитают вопросы с "техниками" обсуждать и тогда уже менеджеры большую часть времени сидят и молчат.
Gryphon88
19.10.2019 23:36Из опыта, я просто ближе к железу, т.е. ещё и немного в инженерию:
1. «Делаем из анодированного алюминия или из стали» — неправильно. Правильно «Какой максимальный вес изделия? Сколько нагрузка?»
2. Неправильно «Ставим обратную связь/энкодеры?», правильно «Какая максимальная точность перемещения?»
3. «Ставим TTL?» — неправильно. Правильно «Сколько интервал между кадрами?»
Ну и так далее. Многие не понимают (честно! особенно увлеченные и начинающие), что заказчику не интересно, какие технологии вы применили, ему нужна работающая штука. На этапе эскиза получилось несколько модулей с разными характеристиками? Идём к заказчику, с ним выбираем в терминах «вот этот движок точнее, но не работает при таких-то комбинациях влажность/температура» или «так получается дешевле, но медленнее».Kanut
19.10.2019 23:41Ну с этим я спорить и не буду. И да, общаться с заказчиком тоже надо уметь. И да, не всем разработчикам это доставляет удовольствие, а для многих это даже просто чистый негатив.
Но пока это всё более-менее добровольно и ты там не один, а с более-менее адекватным менеджером, то почему бы и нет.
П.С. Тем более после таких мероприятий у нас обычно вкусно кормят за счёт фирмы или заказчика :)
kantocoder
19.10.2019 22:24-1Главное чтобы в команде все необходимые роли были заняты и желательно ещё и продублированы. Ну и чтобы при необходимости человека можно было заменить.
Ну как я пытался объяснить, аджайл хорошо подходит для сверхэксплуатации разработчиков. Не нравится пахать по 12 часов в день? Давай, до свидания. Я же говорю, скорее всего аджайл применяют в потогонках (sweatshop'ах).
Это, но в еще большую степень, тот техдолг который неизбежно порождает эта методология, беспокоит меня более всего.
То есть грубо говоря requirements определяют не только менеджеры с клиентом, но в том числе и разработчики которым это потом реализовывать.
Но это и в водопаде делается, разумная практика. Я нередко вместе с сейлзами ездил к заказчикам.
Kanut
19.10.2019 22:47Ну как я пытался объяснить, аджайл хорошо подходит для сверхэксплуатации разработчиков. Не нравится пахать по 12 часов в день? Давай, до свидания
Я не знаю как вы вывели это из написанного мной, но вообще-то это к "аджайл"/"не аджайл" отношения не имеет. Это скорее о том что у вас за начальство и фирма. И что вы сам за человек.
Это, но в еще большую степень, тот техдолг который неизбежно порождает эта методология, беспокоит меня более всего.
Да где именно методология то техдолг порождает? Да ещё и неизбежно? Что вы это повторяете как заевшая пластинка?
Я ведь точно так же могу заявить что водопад "неизбежно" порождает техдолг, потому что есть дедлайны к которым надо успеть и они для менеджеров/начальства важнее чем какой то там техдолг…
Но это и в водопаде делается, разумная практика. Я нередко вместе с сейлзами ездил к заказчикам.
Так в том то и дело что в водопаде это иногда делается, но далеко не всегда. И нигде в "методологии" и "правилах" водопада не прописано что это надо делать.
kantocoder
19.10.2019 23:19-1Уже писал, вот это вот: "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 (оценка длительности, проясниение спецификации и коммуникация с заказчиком) также считалась частью работы инженера.
Kanut
19.10.2019 23:31Нигде не написано, что документация так же важна
Так нигде и не написано что она не важна. И здесь речь идёт о том что лучше иметь рабочий софт без документации, чем полноценную документацию без работающего софта. Или вы несогласны с таким подходом и считаете что документация важнее? :)
Во-вторых, излишняя гибкость приводит к тому, что никому не интересно думать на несколько шагов вперед;
Очень интересное утверждение, которое как минимум требует доказательства.
И я точно так же могу заявить что в водопаде вся ответственность лежит на менеджере, а не на разработчиках и поэтому им тоже "неинтересно думать на несколько шагов вперёд" и делать нормальную архитектуру :)
Ваша аргументация из серии "Аджайл хороший, вы просто не умеете его готовить". Возможно и так. Но зачем нужна методология, которой трудно следовать правильно, и легко — неправильно?
Это проблема абсолютно любой методологии. И водопад здесь тоже не исключение.
Просто раньше был только водопад и для многих ситуаций он подходил очень плохо и поэтому придумали аджайл. И теперь есть выбор. Вот и всё.
Не иногда, а зачастую.
Даже если и "зачастую", то это как бы не является частью методологии и не все до этого доходят своим умом. И от того что в аджайл-методиках это специально прописали они хуже не стали :)
kantocoder
19.10.2019 23:42-1Очень интересное утверждение, которое как минимум требует доказательства.
Очевидно: зачем думать на несколько шагов вперед, если спецификация is not set in stone, и может легко быть изменена заказчиком.
И я точно так же могу заявить что в водопаде вся ответственность лежит на менеджере, а не на разработчиках и поэтому им тоже "неинтересно думать на несколько шагов вперёд" и делать нормальную архитектуру :)
Архитектуру делает архитектор или сами разработчики, когда спецификация зафиксирована и не будет изменена заказчиком.
Просто раньше был только водопад и для многих ситуаций он подходил очень плохо и поэтому придумали аджайл.
Для веба водопад плохо подходил, и для веба придумали аджайл. Но теперь аджайл пихают даже туда, куда его не надо пихать.
У вас какой стэк разработки? У меня hardcore С++, CUDA/MPI, Линукс. И мне аджайл не нужен.
Kanut
19.10.2019 23:59Очевидно: зачем думать на несколько шагов вперед, если спецификация is not set in stone, и может легко быть изменена заказчиком.
"Аджайл" это всё-таки не так, что можно в любой момент потребовать абсолютно любых изменений. Всё равно есть долговременные спецификации продукта и архитектура. И все будущие изменения ТЗ либо совместимы с этой архитектурой, либо подразумевают под собой полный снос проекта и начинание всего дела с нуля за счёт заказчика.
Архитектуру делает архитектор или сами разработчики, когда спецификация зафиксирована и не будет изменена заказчиком.
И? Зачем им делать нормальную архитектуру если они всё равно ни за что не отвечают? Сделают как пойдёт, а остальное пусть потом менеджер клиенту объясняет :)
Для веба водопад плохо подходил, и для веба придумали аджайл. Но теперь аджайл пихают даже туда, куда его не надо пихать.
Водопад плохо подходил не только для веба но и для кучи других вещей где нужно было быстро реагировать на какие-то внешние факторы.
А то, что аджайл сейчас пихают куда не попадя, не делает аджайл сам по себе плохой методологией.
У вас какой стэк разработки? У меня hardcore С++, CUDA/MPI, Линукс. И мне аджайл не нужен.
Вам ещё несколько раз написать что я абсолютно не считаю что аджайл нужен всем и везде? Если вам он не нужен, то я не собираюсь вас уговаривать его использовать.
Просто во первых если вам он не нужен, то это не значит что он не нужен никому и/или плох сам по себе.
А во вторых ваши заявления, что аджайл обязательно порождает техдолг или приводит к тому что люди работают по 12 часов, это не соответствует действительности и просто какая-то чушь.
oldschoolgeek
20.10.2019 08:30Накопление техдолга и «костыльная» архитектура — это следствия бизнес-приоритетов заказчика, а не методологии. Иногда, кстати, такие приоритеты оправданны (например, в стартапах на ранних стадиях, когда в рамках ограниченного бюджета нужно быстро перебирать разные варианты продукта и смотреть, какой из них лучше воспринимается рынком).
Печальные последствия наступают, если накопленный техдолг не обслуживается и не погашается в долгосрочной перспективе, и то не всегда (лично видел «франкенштейнов», годы и годы живущих на костылях и подпорках).
Что же касается методологии, то аджайл — это просто единственное, что хоть как-то может работать в таких условиях.vdshat
21.10.2019 09:29например, в стартапах на ранних стадиях, когда в рамках ограниченного бюджета нужно быстро перебирать разные варианты продукта и смотреть, какой из них лучше воспринимается рынком
Вот об этом и речь, что «мы не знаем что делаем, ввяжемся в бой, потом посмотрим» Это как раз подход диллетантов без опыта. И как раз такие манифесты поощряют такие подходы. Поэтому и вопрос: кому выгодны, чтобы такие подходы работали у вас? Как раз конкурентам ;) Чтоб развалить основу — передачу знаний и наработок: зачем писать доку, если можно не писать? Написано же! Потом через время вас можно брать голыми руками, т.к. вы не владеете ни экспертизой, ни ситуацией. Вы колония…Kanut
21.10.2019 10:06Вы прямо тут триллер написали :)
Всё это конечно тоже имеет место быть, но проблема в описываемых вами ситуациях не в аджайле как таковом, а в самих дилетантах. Забери у них "аждайл" и заставь делать водопад и ситуация на мой взгляд не особо изменится.
Фирма в которой я сейчас работаю существует аж с 95-го года. У неё основной клиент это огромный концерн, с которым работают уже лет двадцать это точно. С большинством остальных клиентов тоже не меньше десяти. Где-то пять лет назад перешли на скрам именно потому что водопад создавал определённые проблемы и нам и клиентам. С тех пор и нам проще и клиентам удобнее.
П.С. До этого работал в консалтинге и там на всякое успел насмотреться. И на мой взгляд проблема обычно не в методиках, фреймворках и языках программирования, а в самих людях.
vdshat
21.10.2019 10:17Вот вы четко описали ситуацию. Вы, по факту, работаете на одного клиента и ему интересно иметь полный контроль над вашей командой. Аджайл как раз для этого и создавался — контроль над рабами на галерах. Поэтому народ и возмущается внедрением аджайл, т.к. это подспудно подразумевает превращение их в рабов. Понятное дело, что сама методология, как и любой, практически, инструмент может использоватся в разных целях. Но изначальная цель для аджайл, все таки никуда не девается
Kanut
21.10.2019 10:22И чем в этом плане аджайл отличается от водопада? Почему когда мы делали водопад мы не были "рабами", а когда перешли на скрам, то внезапно ими стали?
sergey-b
20.10.2019 00:50+1Вот это меня больше всего отталкивает в эджайле. То, что если он у вас не работает, то это не эджайл плохой, а вы просто не умеете его готовить. Мне нужна такая методология, в которой я могу взять методичку и самостоятельно оценить, правильно я действую или нет. И если я сам не разберусь, то могу позвать эксперта, который имеет успешный опыт, и он мне скажет конкретно, что я должен изменить.
Если нормальных методичек нет, а все эксперты не могут сказать ничего, кроме того, что у всех кругом Faux Agile, то эта методология для продуктивной работы не годится.
Kanut
20.10.2019 10:34Мне нужна такая методология, в которой я могу взять методичку и самостоятельно оценить, правильно я действую или нет. И если я сам не разберусь, то могу позвать эксперта, который имеет успешный опыт, и он мне скажет конкретно, что я должен изменить.
А с аджайлом это точно так же работает как и с любой методикой, например с водопадом. И если брать конкретно скрам, то он тем и хорош что есть очень жестко прописанные правила и им надо следовать. И если ты им не следуешь и начинаешь скрам под себя "кастомизировать", то в 99% случаев ты получаешь что-то неработоспособное.
Ну и мы например на старте брали человека со стороны чтобы он смотрел всё ли мы правильно делаем и потом таких людей пару раз приглашали для контроля/консультации.
П.С. И на мой взгляд если кто-то начинает "кастомизировать" скрам нарушая при этом его правила, то это скорее всего значит что скрам(а модет и аджайл в уелом) ему просто не подходит. Ну или что в фирме есть какие-то другие более важные проблемы, которые надо рншать в первую очередь.
vdshat
21.10.2019 10:37Ну и мы например на старте брали человека со стороны чтобы он смотрел всё ли мы правильно делаем и потом таких людей пару раз приглашали для контроля/консультации.
Интересно, сколько человек со стороны вникал в вашу ситуацию? У нас, по опыту, нужно от 3х месяцев, т.е. человек должен полностью погрузится в команду и область, т.е. работать у нас. Пару раз начальство присылало коучей, ну и? Как пришли, так и ушли. Сейчас опять вместо тех лида или старшего разработчика взяли Scrum Mastera… Графики красивые рисуем, но как не успевали заказчику отдать вовремя, так и не успеваем, т.к. тупо не хватает людей на хотелки.Kanut
21.10.2019 10:42Интересно, сколько человек со стороны вникал в вашу ситуацию?
Он у нас полгода где-то был в первый раз.
Сейчас опять вместо тех лида или старшего разработчика взяли Scrum Mastera…
Скрам-мастер это вообще никоим образом не замена техлиду или разработчику. Он вообще никаких решений принимать не должен и его задача это следить за организационными вопросами и решать проблемы команды связанные с "внешним миром". Он по идее даже внутри команды никакие решения не может принимать если они не связаны конкретно с выполненнием правил скрама.
Viceroyalty
19.10.2019 18:51У аджила и скрама есть описание когда они помогут и когда они НЕ помогут, а помешают?
Если нет — их трудно воспринимать серьезноKanut
19.10.2019 19:14+1Есть рекомендации когда скорее стоит использовать аджайл, а когда скорее не стоит. Так же есть рекомендации какая конкретная аджайл-методика скорее подходит в какой ситуации.
И аджайл/скрам это не серебрянная пуля и они подходят далеко не для всех фирм.
Viceroyalty
19.10.2019 19:23>>>И аджайл/скрам это не серебрянная пуля и они подходят далеко не для всех фирм.
Это нужно высечь в граните
Viceroyalty
19.10.2019 18:51Окликнулась как-то на резюме одна контора. Читаю описание вакансии созваниваемся, говорю мол вряд ли я вам подхожу, я C++ ник а у вас тут Ява, девочка такая — там писать на Яве не надо — только читать, что написали другие (должность была вроде аналитика по улучшению кода/архитекруты), дрижой пользоваться умеете? Нет говорю.
Проходит несколько дней, девочка звонит снова, говорит — у нас проблема была с Джирой — вы не умеете ей пользоваться?
То-есть знание ЯП им до лампочки, а Джира возведена в карго-культ ;)khim
19.10.2019 19:23Ну потому что Джирой же даже она может пользоваться… Так что что можно сказать о человеке, который даже этого не умеет?
Viceroyalty
19.10.2019 19:28Что он Джиру никогда не видел и смотреть не собирается, раз отказывается от вакансии так-как не является гуру Явы?
Только когда писал ответ дошло, что это был сарказм — тонко.
А вообще слово аналитик в названии должности нужно запретить законодательно — это имя слишком перегружено
kantocoder
19.10.2019 20:05У меня постоянно ощущение, что открыли фабрику по клонированию дураков. Не может быть, чтобы их столько естественным путем народилось.
Gryphon88
19.10.2019 21:52+2Просто коммуникации стали доступнее, вот мы и стали заметнее :)
Viceroyalty
19.10.2019 22:01Самокритично
Gryphon88
19.10.2019 22:11А то. Если раньше, чтобы в области, в которой я не разбираюсь, дать совет безбрежного масштаба и не меньшей глупости я мог только лично, на посиделках с друзьями, то теперь у меня Интернет есть! Серьёзно, если раньше в состоянии умственной расслабленности, которая бывает у всех, чтобы донести своё мнение надо было затратить силы: пойти или написать письмо, то теперь в кармане доступ к широковещательному каналу.
sbnur
19.10.2019 15:06"Например тимлид должен нанять программиста, лучшего чем она" — что за перевод — в оригинале — engineering manager — никак не тимлид — но не это главное — вопрос к автору — как можно оценить лучшего, если твой уровень ниже. Кажется, обычно более опытный оценивает менее опытного
И кстати, кто это онаdominigato Автор
19.10.2019 15:08who is a better programmer than she is
Так и было в оригинале, я ничего не менял :) Диверсити, все дела.Stiver
19.10.2019 16:38Это 'generic she', оно же 's/he' — переводится как 'он/она'.
lorc
19.10.2019 16:47Обычно в таких случаях говорят they, разве нет?
SlimShaggy
20.10.2019 20:34Использоваеие they в этом случае считается грамматически некорректным, т.к. это множественное число там, где по смыслу должно быть единственное. Но за отсутствием вменяемых альтернатив и так говорят, да.
khim
20.10.2019 21:11Непонятно — можно ли считать грамматически некорректным вариант, который используется не одно столетие.
Но я использую s/he. Не потому что считаю they грамматичски некорректным, а потому что не верю в историю о 100500 полов. S/he — чётко показывает, что тут либо He, либо She — и нам неважно кто. They — это архаизм, вытащенный откуда-то SJW и превращённый в фетиш.SlimShaggy
20.10.2019 21:36Ну так он не одно столетие некорректным и считается :) И мне всегда казалось, что используется он просто чтобы не городить неуклюжие конструкции типа вашего s/he (кстати, как вы это произносите)? Но справедливости ради надо сказать, что с учетом небинарных гендеров я на этот вопрос никогда не смотрел. Пожалуй, буду тоже использовать they, чтобы уж точно никого не обидеть (граммар наци не в счет).
khim
20.10.2019 23:11Пожалуй, буду тоже использовать 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, как обычно, зрит в корень:
Неужели не видели?
Am0ralist
20.10.2019 23:31или так, его уже давно переводят
SlimShaggy
20.10.2019 23:33Вот прямо так написано: 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.Am0ralist
20.10.2019 23:40Ну в случае StackExchange таки удастся — там явно сказано
Через пару лет такое обращение станет опять угнетающим.
на примере дрейфа понятий черный/негр/афроамериканец и калека/инвалид/люди с ограниченными возможностями. Каждый раз новый термин был призван убрать негативную коннотацию предыдущего
khim
21.10.2019 11:23Не вижу проблемы. Называть человека так, как он просит его называть — элементарная вежливость.
А я вижу. Чтобы называть человека «так, как он просит его называть» — нужно провести опросы, где-то это зафиксировать, создать комиссии, которые будут вот всё это рассмастривать и прочая-прочая.
Всё это — движение на пути к тому, что люди, которые обладают нулевой технической компетенцией будут решать что, как и когда делается. Ну как в Российской космической промышленности — хотя и по другому поводу.
Ну в случае 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 хотят знания математики или там программирования? Фиг — самое важное, чтобы вы мужика в платье по имени-отчеству не называли, а говорили «она» (ну или «оно» — но только так, как этого от вас просили)… и шоб не путали никогда!
0xd34df00d
21.10.2019 16:05+1Не вижу проблемы. Называть человека так, как он просит его называть — элементарная вежливость.
Если человек на SO попросит называть его «master of slaves», нужно ли выполнять эту просьбу?
Или, если вы любитель поиграться с логикой, что делать, если у него в этом поле будет «please don't call me by my preferred pronoun»?
transcengopher
21.10.2019 16:12Кстати, на первый вопрос официальный ответ уже имеется — если ваши pronouns модератору не по вкусу — то можно и не называть. Правда, тогда это строго говоря "denying your lived experience" и прочий джаз, но модератор может не вмешиваться. Эта вся ситуация как с религиозными писаниями, там уже толкователи появляются.
0xd34df00d
21.10.2019 16:31Тогда вообще непонятно. Ну не по вкусу какому-нибудь модератору называть людей местоимениями с подразумеваемым гендером, отличным от данного по рождению. Или вообще по каким-либо местоимениям (за что Монику-то выгнали тогда?).
Или, что ещё круче, не по кайфу называть кроме как he. Потому что, как модератору известно, в интернете девушек нет.
transcengopher
21.10.2019 18:32А тут фишка в том, что в интернете есть огромные словари этих нео-местоимений, и модератору, как я понимаю, будет разрешено обращаться к своему вкусу только если вашего местоимения в словаре нет (что, кстати, иронично, т.к. отсутствие чьих-то уникальных как снежинка местоимений в обыкновенных словарях всегда называется большой проблемой). Впрочем, отсутствие в словаре элементарно решается — созданием собственного словаря+1 где-нибудь на тумблере, а как решается вопрос с мусорными словарями — пока неясно, придётся ждать версии словаря с личными местоимениями за авторством 4chan, видимо.
transcengopher
21.10.2019 16:07Называть человека так, как он просит его называть — элементарная вежливость.
Элементарной вежливостью это было до того, как за отказ подчиниться начали выгонять. Согласитесь, тяжеловато быть искренне вежливым когда за невежливость вас линчуют.
Если прочитать ответы работников StackExchange (не модераторов, а именно людей на зарплате) на многочисленные вопросы про новую политику, то ясно видно, что правил, с этим связанных, по факту нет. Например, если в длинном чате вы пользуетесь юзернеймом, и при этом оный юзернейм неделю назад просил вас обращаться к нему "кхия" (и не забудьте это слово просклонять правильно, а не то), а вы забыли (потому что таких же юзернеймов вы, как человек, отвечающий на тупые вопросы, за неделю были вагон и тележка), юзернейм может пожаловаться на вас модераторам. И начиная с этого момента всё зависит исключительно от того, был ли модератор в хорошем настроении сегодня, т.к. правила на этот счёт имеют два противоположных утверждения. Если настроение было плохое — ну, создавайте другой аккаунт на SO, предыдущий-то всё. Случай, разумеется, утрированный, но общее ощущение от новых правил такое, что смысл не в том, чтобы все жили как завещал кот Леопольд, а в том, чтобы всегда под рукой была благовидная палка, которой вас можно выгнать, если что.
0xd34df00d
21.10.2019 16:03В англоязычных коммьюнити, озабоченных дивёрсити (аж в рифму, лол) можно троллить тех, кто говорит s/he, тем, что они слишком бинарны и нетолерантны к неклассическим гендерам.
Получается, кстати, довольно забавно.
Kanut
21.10.2019 16:09Это ладно. В Германии после всех этих дебатов и чтобы быть потолерантнее некоторые фирмы стали в вакансиях писать (m/w/d), есть (mannlich/weiblich/drittes) оно же на русском (мужчина/женщина/третье). Но кто-то "расшифровал" это как "mannlich wei? deutsch", то есть "белый немецкий мужчина". И теперь это стало местным мемом :)
0xd34df00d
21.10.2019 16:35третье
Всего одно третье?!
Kanut
21.10.2019 16:38Всего одно третье?!
Ну вобщем то это на мой взгляд корректное "подразделение". Потому что "третье" при необходимости можно подразделять дальше.
Раньше просто в таком случае писали только (m/w).
П.С. В данном случае "третье" можно понимать как "иное". Можно сказать особенности языка.
0xd34df00d
21.10.2019 16:42То есть, весь остальной спектр гендеров настолько неважен, что вы его упаковываете и ставите на тот же уровень, что и один из классических гендеров?!
Ладно, надо прекратить играть в обиженку, а то вдруг понравится, привыкну ещё.
Kanut
21.10.2019 16:46То есть, весь остальной спектр гендеров настолько неважен, что вы его упаковываете и ставите на тот же уровень, что и один из классических гендеров?!
А тут смотря как смотреть. Если например исходить из частоты появления в популяции, то это даже перебор получается.
С другой стороны указывать какие-то конкретные варианты в общем-то и не запрещено и наверняка кто-то так и делает если это играет какую-то роль. Хотя хоть убейте меня, но мне сейчас в голову ни один пример не приходит :)
П.С. И большинство фирм вообще ничего не указывают если нет конкретных ограничений.
Am0ralist
21.10.2019 17:12Интересно, если у нас начнут писать (м/ж/оно) — какая реакция у третьих будет? )
khim
21.10.2019 20:37можно троллить тех, кто говорит s/he, тем, что они слишком бинарны и нетолерантны к неклассическим гендерам.
Любой каприз за ваши деньги. Хотите чтобы я запоминал, что Вася сегодня не «он», а «кхия» — платите. Не хотите платить — ну так я вас читать вообще не заставляю.
P.S. И да, если работодатель готов за это платить — то это другая история. То есть понятно, что вот это вот увлечение разноцветием полов и прочим — одного поля ягодки с постоянно меняющимися ГОСТами на чертежи… но если для вас важно, чтобы торерантность соблюдалась, а будут ли падать ракеты — неважно… ну значит так тому и быть. Но если я должен этим заниматься бесплатно… извините…
divanus
19.10.2019 15:08+1Добавлю в список:
Нанимать оптимизатора бизнес-процессов, который их оптимизирует основываясь на работе с руководством, а не с людьми в полях.
Обязательно внедрять технику applе: всем по планшету, смартфону, макбуку.
работники начинают заниматься диджейством и всякими другими фишками и ништяками
В офисе все начинают носить бороду
Совещания проходят каждый день и занимают от 1 до 3 часов
Обязательные видеосовещания с филиалами — так же идут от 1 до 3 часов
Приглашается Бакшт!
Так же все начинают хоить на успешный успех!mSnus
19.10.2019 15:35+5Да, если даже красивые девочки с ресепшена начинают носить бороды, то с компанией что-то не в порядке
shinsheel
19.10.2019 15:44-1Внедрение Эппла на самом деле хороший маркер.
Обьективно-то идея неплоха — железо Эппл делает хорошее, стандартизированное, при этом вполне юзабельное, если насаждать монокультуру из техники одной фирмы то Эппл неплох.
Но чтобы её претворять в жизнь в компании уже должна быть нездоровая концентрация полномочий.
apapacy
19.10.2019 17:17Ага. Это означает что уже никто не будет вкалывать в четырьмя мониторами присоединенным к одному десктопу. А все разделятся на две части. Одна половина будет елозить по тачпаду а другая задумчиво ходить по офису поглаживая тачскрин в бесконтактных наушниках.
Am0ralist
19.10.2019 19:22Всё таки это зависит от того, кому выдавать и для чего.
Для менеджера в полях бегающего ради отчетов ежедневных в вашей системе — да, по мне планшет от эпла будет лучше, чем планшет на других ос)shinsheel
20.10.2019 15:41Как хороший пример, кстати, Приватбанк. Везде где был у тех кто работает с клиентами айпады. Дуракоустойчиво, надежно, взаимозаменяемо.
Может делать фото и принимать подписи.
Реальный софт крутится на серваке через веб-морду.
Поначалу жирно кажется, но по факту с такой стандартизацией вообще исчезают проблемы поломок — в крайнем случае за углом всегда можно отремонтировать или купить новый с точно такими же параметрами
Там где все-таки стоят десктопы тоже все через веб-морду, но с убунтой. Тут как-бы от обратного, но по сути тоже самое — дуракоустойчивость у убунты огромная и поддержка любого железа редко бывает такой плохой чтобы с кривыми руками не работала одна страничка в браузере.
Lazytech
19.10.2019 15:31+2Лингвистический оффтопик
Нашел возможное происхождение выражения 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
В связи с этим вспомнилась известная поговорка «рыба гниет с головы».Lazytech
19.10.2019 16:17+1Вспомнилась известная книга:
Сирил Паркинсон. Законы Паркинсона (полный текст)
Вкратце:
Закон Паркинсона — Википедия
НЕПРИЗАВИТ (в другом варианте перевода — БЕСПОЗАВИЯ)
Состоит из трёх стадий.
1. Среди сотрудников появляется человек, сочетающий полную непригодность к своему делу с завистью к чужим успехам. Наличие его определяется по внешним действиям, когда данное лицо, не справляясь со своей работой, вечно суётся в чужую и пытается войти в руководство.
2. Носитель заразы в какой-то степени прорывается к власти. Нередко всё начинается прямо с этой стадии, так как носитель сразу занимает руководящий пост. Опознать его легко по упорству, с которым он выживает тех, кто способнее его, и не даёт продвинуться тем, кто может оказаться способнее в будущем. Результат — штаты постепенно заполняются людьми, которые глупее начальника. Признаки второй стадии — полное самодовольство. Задачи ставятся несложные, и потому сделать удаётся, в общем, всё. Начальство добивается того, что намечено и становится очень важным.
3. Во всём учреждении, снизу доверху, не встретишь и капли разума. Признаки — самодовольство сменяется апатией.
В общем, ничто ни ново под луной. :)
1c80
19.10.2019 17:57А есть ли у кого примеры, когда начавшиеся одебиление потом удачно прошло? Я про компании которые выпускают какой то конкретный продукт и у которых есть много конкурентов.
Мне-то кажется, что это начало конца для них и выздоровевших не наблюдал, но может я ошибаюсь?Gryphon88
19.10.2019 21:57Про IBM интересно читать. Там 1993 там очень удачно CEO наняли и дали работать, тот разогнал значительную часть бюрократии, продал традиционные, но убыточные направления, в итоге доходы поползли вверх.
Вообще, «раздебиливание» во многом похоже на внедрение CRM: для успеха должны быть желающие успеха начинанию и вверху (работают толкачами), внизу (демонстрируют эфект и реализуют «воспитание коллективом» по Макаренко).
GeorgKDeft
19.10.2019 18:10Если у вас есть еще признаки «одебиливания», оставьте их в комментариях, я их добавлю
Не знаю как у кого… но у меня если на работе начинают бухать просто так — это явный признак скорого «дна».Gryphon88
19.10.2019 21:59Но в пятницу после работы, часто сочетая с бэклогом, или после закрытия проекта — нормально. Хуже, когда каждый день у кого-то день рождения или иной праздник — все собираются на обеде посидеть и задерживаются в лучшем случае на часок.
Londoner
19.10.2019 19:37А какие вопросы стоит задать на собеседовании, чтобы не вляпаться в такую компанию?
shinsheel
20.10.2019 05:28+1* Субьективно — если тебя собеседует эйчар это уже плохой знак.
* Если эйчар делает что-то более чем первичный фильтр — ещё хуже.
* Если твоим боссом будет менеджер который сам не технарь это плохой знак(исключение — если это сооснователь или глава филиала)
Срачегонные критерии:
* Много девушек, особенно на высоких должностях. Девушки на порядок больше любят более стабильные и бюрократичные компании где все четко расписано.
* Друзья и родственники начальства в компании, только если это не кофаундеры
* Компания использует технологии которой ты бы сам не стал пользоваться в их ситуации
** Бонусные очки — если это продиктовано чисто бизнес-соображениями, типа того что у вас Microsoft в партнерах и потому пользуемся только тем что поддерживает Ажур
* Любовь к любым государственным статусам, регалиям, бумагам итд, ну и ватность в целом. К ней склонен тот тип руководителя который и разводит у себя в компании вертикаль начальник-дурак. (спроси чей Крым, ага)
* Любовь к продукции Эппл, Майкрософт или любой другой без понятной причины. Скорее всего это потому что «никого ещё не уволили за то что он купил IBM»
Дисклеймер:
Все предыдущее безусловно плохо только в контексте bozo explosion. Большинство людей работают в компаниях где он уже произошел, большинству даже нравится.
VMichael
19.10.2019 20:21+3Не очень понятна целевая аудитория статьи. К кому автор обращается?
Если к боссам, так они это не читают, слишком поверхностно.
Если к сотрудникам, так у них полномочий нет что то менять, они же не боссы.
Или так, потешить самолюбие рядовых, которые могут представить, чтобы они сделали если бы были боссами?
Для рядовых один совет: замечаете срань вокруг и не видите возможности карьерного роста до позиции, где сможете на что то влиять в этой компании, попытайтесь найти работу в компании более здоровой.
gerasimenkoao
19.10.2019 21:47Одебиливание? В больших компаниях это происходит повсеместно!
Вспомните лабы в институте, больше трех — эффективнось падает!
Джефф Безос сформулировал правило дву пицц, но но гораздо ранее оно появилось у воров.
Колода вроде — 5 человек, каждый обладает уникальным навыком — щипач, медвежатник и т.д.
Отсюда и "шестерка" — "лишний" в наборе, которого и пускали на рисковые дела.
Это так, из передачи "следствие вели с Каневским".
А по сути — одебиливние — это следствие глобализации — "скованные одной цепью" — помните?
Когда в любом уголке планеты магнитики с с названием и символом посещаемого места имеют надпсь "Made in China" на обороте.
Кроме еды в ресторанах, невозможно приобрести ничего произведенного локально в посещаемом регионе.
Нынешний мир устроен так, чтобы максимально вовлечь индивидуума в колесо системы, вся действительность указывает на то, что один в поле не воин, что за пределами большой корпорации отдельный человек — никто, и малый бизнес не попрет против большого.
В общем — одебиливание — оно повсеместно, и в головах, подобно "разрухе" у Преображенского.
dim2r
19.10.2019 22:24Еще один заметил способ одебиливания — акцент на средства, а не на цели. То есть человек должен в совершенстве знать язык программирования, но не должен задаваться вопросом «для чего ?», «для каких целей?». В результате проекты, в которые его ставят становятся все более невыносимыми.
Gryphon88
19.10.2019 22:35А по-моему, знать язык, но не знать предметную область, в которой будет применяться программа, нормально для программистов нижнего уровня при грамотной работе вертикали командования. Думают менеджеры, архитекторы и тимлиды, а софтогонный агрегат имеет на входе что-нибудь типа UML или спеки.
dim2r
20.10.2019 10:05Для программиста имеет смысл качество проекта и качество жизни.
У меня было несколько друзей, с которыми можно было интересно поговорить, но при переходе на отстойные проекты они перестали понимать анекдоты и все время смотрят в пол. И только твердят — учи джаву, учи джаву.
masterdak
19.10.2019 22:47Вы серьезно считаете, что можно дать несколько простых советов, и это избавит компанию от скатывания к посредственности?
apapacy
20.10.2019 02:13Если внимательно почитать текст статьи, то она носит скорее характер иронии. И советы также это не столько советы, сколько ирония на тот счет как дела обстоят на самом деле.
Что касается адресата статьи. То она конечно направлена в первую очередь грамотным разработчикам, чтобы те не сильно комплексовали на тот счет "да что он о себе возомнил"
Но есть люди которые могли бы быть заинтересованы — это владельцы бизнеса. В отличие от пафосных менеджеров среднего и высшего уровня (иногда они тоже всего лишь наемные рабочие но на сказочных окладах). Однако в контексте этого термина (взрыв Бонзо) обычно подразумевают слетевшее с катушек среднее звено менеджмента.
nickolaym
20.10.2019 02:33+2Например тимлид должен нанять программиста, лучшего чем она
Опа, тимлид-гендерфлюид!
Понятно, что это дань феминитивщине, — что теперь дефолтное местоимение стало she, но
1) понятно и другое: род глагола надо было согласовывать и с тимлидом, и с "ней"
2) давайте не будем страдать общечеловековой фигнёй
AyratK
21.10.2019 14:36ИМХО, антиодебиливающие советы ни о чем. Вы просто добавили очередные лозунги. В больших организациях проблема не в лозунгах — их как раз всегда хватает. Умелый бюрократ любой лозунг сможет использовать в своих личных целях. И чем больше лозунгов — тем проще бюрократу.
Проблема больших организаций в отсутствии адекватных институтов (подразделений, позиций, ролей) которые бы эффективно противостояли обюрокрачиванию. Института государственной власти это касается в первую очередь.Gryphon88
21.10.2019 14:53Мне кажется, это скорее сборник маркеров «Пора уходить из компании. Дальнейшая работа может быть хлебной, но при этом бессмысленной и бесполезной»
AyratK
22.10.2019 10:16Кому как. Зависит от того, что нужно от работы и в чем ее предмет. Бывают в таких компаниях такие руководители, которые могу защитить (сгладить эффекты) подчиненных от влияния сверху. Но как правило такие руководители высоко не идут — ценны на своем месте. Выше важен другой скиллсет.
Для некоторых такие компании — основной предмет работы. Например, внедренцы\разработчики систем ERP вроде SAP. Сплошь такие клиенты (особенно на пространстве бывшего СССР).
eshirshov
21.10.2019 14:43Я работал всё больше в мелких-средних компаниях.
Так, что и симптом попроще, хотя смысл тот-же:
основатель-владелец покупает-строит дом-дачу-яхту.Kanut
21.10.2019 14:46Какаой-то странный симптом… То есть сотрудникам можно покупать-строить дом-дачу-яхту, а основателям и владельцам нет? Или вообще никому нельзя?:)
sergo1979on
22.10.2019 10:58Полностью согласен с автором, но во многом все зависит от руководства и хозяина компании, будет больше платить ставить интересные задачи и коллектив хороший соберет тогда.
LedIndicator
22.10.2019 10:58Например тимлид должен нанять программиста, лучшего чем она
Понятно, что в современных США согласовать существительно с «он» это сексизм и дискриминация, даже «they» уже не катит, но в русском языке, даже если это перевод с американского английского, тимлид это пока ещё он.
pakh
22.10.2019 10:58"Настаивайте чтобы менеджеры нанимали лучших менеджеров чем они сами". Что значит "настаивать"? Если повторять это настойчиво и на каждом совещании, то смело можно добавлять еще одним пунктом к одебиливанию. В подавляющем большинстве компаний менеджеры не заинтересованы нанимать людей сильнее себя. Там, где это не так, одебиливание компании точно не грозит. А где так — существует ли хитрый механизм, который засвталял бы менеджеров нанимать людей сильнее себя? Я про такой механизм ничего не знаю. Единственный крайне рискованный ход — это властителю или группе властителей компании жуть как захотеть раздебилить свое детище. Для этого не ошибиться в поиске нужной команды консультантов, не пожалеть на это кучи денег и 3-5 лет геморроя и быть готовыми заменить 50% персонала.
Искореняйте высокомерие и снобизм. Снова вопрос про корпоративную культуру. Ну, если кто-то главный очень захочет и будет стучать по голове каждому, кто проявит эти качества — со временем они перестанут проявляться вовне. А когда-то, быть может, исчезнут и внутри. Но, поскольку рыба гниет с головы, вряд ли такой главный найдется.
Не нанимайте с излишком. Думаю, этим могут болеть только госкорпорации. А в большинстве из них дебилизм непобедим и дергаться бесполезно.
Я бы предложил намеренное сдерживание продаж. Это на падающем-то рынке????
DrunkBear
22.10.2019 11:34Ещё один пунктик: перекуп человека из Очень Крутой Компании с MBA (в идеале — с 12 пункта) за х2 его зп, о чём должно сообщаться с придыханием: «Мы перекупили продажника из <технологическая компания> в нашу <компания продажи одежды> с MBA! За зп как у всего нашего отдела! Вааау!!!!»
Ну и как же без карго-культа? Всё начинается с митинга «Я тут был заграницей в Риц Карлтон и встретил топа из ххх, они используют продукт XYZ — нам он тоже необходим! С понедельника срочно все переходим на XYZ и начинаем жить по-новому!» — при этом оценки «зачем продукт, почему его используют, какие у него слабые стороны» естественно не происходит.
Viceroyalty
Нам бы так