Как предотвратить одебиливание компании?

Автор оригинала: Guy Kawasaki


Как-то больно смотреть как крутая, эффективная и боевая компания скатывается в тупую посредственность и середнячковость. В Кремниевой Долине мы это называем «одебиливанием» (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 для компании советом директоров.

Искореняйте высокомерие и снобизм


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

Не нанимайте с излишком


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

Не распухайте


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

Смотрите на человека, не только на резюме


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

Вносите разнообразие


Некоторые компании выглядят как загоны для овечек Долли, как будто всех работников клонировали. Например у всех есть докторская. Или все росли в семье из среднего класса. Или ходили в одну секцию дзюдо. Или все учились в «Лиге Плюща». В конце концов получается какая-то армия клонов. Когда это случается, это значит что форма превалирует над содержанием, и людей ценят не за их поступки и действия, а за то насколько они соответствуют форме. Эта дорога ведет глубоко вниз.

Сокращай и соединяй


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

Подробнее
Реклама

Комментарии 277

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

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

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

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

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

                    +12

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


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

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

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

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


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


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

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

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


                        Почему Вы думаете, что это связано? Операционки от MS и Apple тоже стоят в миллиарде устройств, но в качестве системы контроля версий там сейчас, насколько мне известно, пользуются гитом. Хотя обе эти компании в свое время страдали NIH синдромом более, чем широко. Кстати, в качестве основных языков для разработки под Android выбрали сначала чужую Java, а затем чужой Kotlin.
                      +13
                      Перевод конечно вольный — я бы сказал, не просто вольный, а прям какая то адаптация сериала.
                      Оригинал
                      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. Земфира поет на вашем новогоднем корпоративе.


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

                        Корейский автопром корнями уходит в древние японские разработки. Так, к слову.
                        Но вот что интересно — корейские автомобили в Японии не продаются (по крайней мере официально).
                          0

                          Как не продаются? А эти что делают?


                          http://www.hyundai-motor.co.jp/

                            0
                            Вот ссылка на видео, блогер в автотеме крутится и есть основания ему доверять.
                              0
                              Спроса нет на самом деле. Купить можно, но это надо очень постараться. Они продавались раньше, но продажи были слабы.
                            0
                            У Японии и Кореи исторически очень теплые взаимоотношения. Настолько теплые, что еще недавно действовали санкции на продажу продукции друг другу.
                            +35

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

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

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

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

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

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

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

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

                                        +5

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


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

                                          +2
                                          Leader vs Boss.jpg
                                          image
                                            0

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

                                              +5

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

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

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

                                              +2

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

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

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

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

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

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

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

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

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

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


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

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

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

                                                              +1

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

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

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


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

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

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

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


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

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

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

                                                                        +2

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

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

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

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

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

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

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

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

                                                                                –1

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

                                                                                  +1

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

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

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

                                                                                  +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.


                                                                                  ...


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


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

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

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


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

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

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

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


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

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

                                                                                          +3

                                                                                          Миссия — штука полезная. Только не все умеют ее готовить.
                                                                                          Миссия — это маяк, на который должны ориентироваться сотрудники при принятии решений. Вот как пример миссия 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 лет работы так и не понял сути миссии текущего работодателя...

                                                                                            +1

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

                                                                                                        +5

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

                                                                                                          +1

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

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

                                                                                                              Смотрите чуть ниже мой коммент — он подробнее и вопросы отпадут.

                                                                                                            +1

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

                                                                                                            +1

                                                                                                            При чем тут девопсы?

                                                                                                              0
                                                                                                              Сейчас распространённая ситуация, когда девочка-хеарщица бегло просмотрев твоё резюме говорит «вы знаете, вы нам не подходите». Если просишь расшифровать почему именно — рассказывает, что не встретила в резюме названий девопс-инструментов, значит, я их не использую, значит я не девопс.

                                                                                                              Тогда я ей указываю на то, что я использовал девопс-инструменты 5..10 лет назад, до того как это стало мэйнстримом и они указаны, просто хайп прошёл и их место заняли другие buzzwords

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

                                                                                                              потому что в 2009 она училась в школе и интересовалось только подготовкой к ЕГЭ

                                                                                                              Постоянная ссылка этого комментария: dissenter.com/comment/5db3f35d6b97a2019af407c9
                                                                                                            +5
                                                                                                            С компанией становится все понятно, когда в ней заводятся коучинг, менторинг, наставничество, миссии, тренинги по управлению эффективностью и т.п. Незаметно вдруг вы замечаете, что 30% времени ваши сотрудники тратят на чтение рассылок с новостями HR, просмотр презентаций о миссиях, корпоративной культуре, участвуют в каких-то конкурсах, номинациях, тестах и прочей лабуде. А на деле оказывается, что HR не способен банально не может подобрать вам кандидатов, потому, чти у них у самих текучка и все, что могут предложить — разместить вакансию на hh и насыпать вам откликов.
                                                                                                              +4
                                                                                                              Что не так с менторингом? Когда более опытный сотрудник помогает менее опытным в решении учебных и рабочих целей это же хорошо.
                                                                                                                +2

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

                                                                                                                  0

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

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

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

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

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

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

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

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

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


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

                                                                                                                      0

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


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

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

                                                                                                                        +2

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


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

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

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

                                                                                                                            +1

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


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


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

                                                                                                                              0

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


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


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


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

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

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


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

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


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

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


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


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

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


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

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


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

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

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

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

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


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

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

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


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

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

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

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


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


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

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


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

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

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

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

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

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

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


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


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


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

                                                                                                                              +2

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


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


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

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

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


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


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

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

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


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


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

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


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

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

                                                                                                                                    +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.
                                                                                                                                    Это просто чушь. Лучшие архитектуры, требования, и дизайны возникают из большого опыта разработки, и тщательного, хорошо продуманного планирования.


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

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


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

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

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


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

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


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

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


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

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


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

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


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


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

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


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

                                                                                                                                        +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


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

                                                                                                                                          0

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


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


                                                                                                                                          1

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


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


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

                                                                                                                                            +3

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

                                                                                                                                              0

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


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

                                                                                                                                                +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
                                                                                                                                                мне вообще не понятны, это просто хаос.

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

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


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

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


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


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

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

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


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

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

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


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


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


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

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

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


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


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

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

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


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


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

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

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

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


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

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


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

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

                                                                                                                                                          –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 (оценка длительности, проясниение спецификации и коммуникация с заказчиком) также считалась частью работы инженера.

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

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


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

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


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

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


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

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

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

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


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

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


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

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


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

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

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


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

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


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

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


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


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

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


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

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

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

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

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

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


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


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

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

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

                                                                                                                                                  +2

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


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

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

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


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


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

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

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

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


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

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

                                                                                                                                              0

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

                                                                                                                                                0

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


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

                                                                                                                                                  0

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

                                                                                                                                                    0

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

                                                                                                                                                      0

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

                                                                                                                                                        0

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

                                                                                                                                                          +2

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


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

                                                                                                                                                            0

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


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

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

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

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


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

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


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

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

                                                                                                                                                                0

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

                                                                                                                                                                  0

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


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

                                                                                                                                                                    0

                                                                                                                                                                    В моём мире веб это постгресы-монги-микросервисы, вот всякое такое.

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

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


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