Бизнес vs программная инженерия

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

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



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

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

    Впрочем, «особенности национального менеджемента» — это тема для отдельного, большого и довольно грустного разговора…

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

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

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

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

    Далее – QA. Понятия обеспечение качества и контроль качества для огромного количества проектов является чем-то далеким и загадочным, как туманность андромеды. И это напрямую вытекает из неполноценного использования скрам-практик. Если continuous testing не реализован на проекте именно как один из процессов жизненного цикла ПО – даже если есть люди, которые в ручном режиме пытаются «нащелкать» баги в UI, такое тестирование иначе чем профанацией назвать нельзя. Результат – баги, выпорхнувшие в релиз из-за такого отношения к QA, наносят такой репутационный и финансовый ущерб компании, по сравнению с которыми затраты на постановку реально эффективного процесса работы с качеством продукта покажутся мизерными.

    Но опять-таки – кто занимается этими метриками, этими подсчетами, этими соотношениями затраченных ресурсов…

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

    Это при том, что проект досконально знают в лучшем случае 2-3 человека из группы, остальные знают его в общих чертах и/или фрагментарно, как следствие если эти, обладающие «тайным» знанием люди выходят из игры, то проще переписать все заново, что повлечет затраты, несопоставимые с затратами на документирование. Плюс к этому – возможность анализа системы на предмет рефакторинга кода или более серьезного реинжиниринга. Плюс к этому – к примеру, вход нового человека в проект. Насколько быстрее оно произойдет, насколько быстрее человек станет эффективным, если с самого начала начнет работать с задокументированной системой.

    И хорошо еще, если на проекте присутствует code review, адекватно реализованная модульная архитектура на базе SOLID принципов, нормальная нотация для структурирования, форматирования, именования переменных разных уровней, классов, методов – это в значительной степени может компенсировать отсутствие документации, но думаю описанная выше идеальная ситуация – скорее исключение из правил…

    Как лечить все эти негативные тенденции в индустрии разработки ПО?

    Как мне видится, главная таблетка тут – образование.
    Чем быстрее многоуважаемое академическое сообщество дозреет до осознания программной инженерии как самодостаточной инженерной дисциплины, а не вечной «падчерицы» у «мачехи»-математики, тем быстрее будут скорректированы учебные программы, надеюсь, больше людей будут приходить из реальной разработки в качестве преподавателей в ВУЗы.

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

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

      +4
      Бизнес это не антагонист инженерии, а скорее ее среда. Проблема в том, что к самим бизнес-процессам редко применяется инженерный подход, чаще это что-то типа: «обезьяна видит — обезьяна делает». И академическое образование тут точно не поможет, в виду недостаточной гибкости у всего академического. Методологии, документация и контроль качества могут являться, и часто являются таким-же манки-бизнесом, как и все вокруг. Решение — в правильных людях, которых просто мало, как золота.
        0
        Люди-то у нас хорошие. Вопрос в опыте и процессах. Потому и кочуют по компаниям тренеры, которые ставят процессы в компании. Из того их состояния где кому-то что-то ясно как надо делать, в состояние когда каждый знает когда и что ему лично надо делать. Поставленный процесс приносит спокойствие. Есть ответственные за каждый этап разработки. И, главное, все знают кто за что отвечает. Каждый делает свою работу, делает ее хорошо и в срок, и главное не делает лишнего (в отделе маркетинга решили, что этот экран за 3 дня до релиза надо полностью переделать, потому как у прежнего была низкая конверсия).
        +3
        ПО создается для бизнеса. Это и есть самый главный заказчик.
        Скрам конечно пытается убить качество кода ради скорости появления новых фич.
        Но никто не мешает обсуждать последствия принятия «простых решений» вместе с бизнесом.
        И записывать это в технических долг.
        Задокументированный технический долг, он уже не долг — а осознанный риск бизнеса. И за него отвечают бизнесмены.
          +2
          Если пожеланий более 100, то риск уже не осознаётся.
          И решение о улучшении обосновывается на понятном заказчику языке: «Реализация желаемой функциональности при текущем подходе будет стоить X, а смена подхода и реализация той же функциональности будет стоить 70% от X».
            0
            Только не 70%, а 100% от X, если требования изменились больше, чем на 25%, ссылаясь на Роберта Гласса
            +1
            Бизнесу почти всегда нужно «здесь и сейчас», даже если потом придётся всё переписывать. Но психологически, очень неприятно тратить много усилий не на создание чего-то нового, уникального, а на очередное «перекапывание канав». По итогам года, гораздо приятней похвастаться «я сделал вот эти 5 фич», чем оправдываться «я сделал эти 3 фичи, и провёл 2 рефакторинга, потому, что каждая фича требовала переписывания всего». И, безусловно, кто платит, тот и решает. Но не стоит недооценивать силу мотивации/демотивации.
              +1
              Бизнесу почти всегда нужно «здесь и сейчас», даже если потом придётся всё переписывать.

              Это нужно недальновидному бизнесу. Правильный вопрос «Что будет сейчас и что будет через месяц, год?».
              Дело, как обычно, в людях.
              Если это не осознают отдельные представители менеджмента, не значит, что это не осознает весь бизнес вообще.
                0
                Так зачастую никто и не знает что там будет через год :-) Особенно когда продукт ещё не запущен. Может не выгорит и получается зря парились. А может и выгорит и будут средства хоть полностью его переписать.
                  0
                  Насчет «Что будет» я не про пророчества) Я про планирование.
                  Можно провести аналогию с ребенком.
                  При зачатии ребенка семья планирует его рождение, делает наметки насчет яслей, детсада, школы, и т.д.
                  Естественно, все может поменяться — переезды и т.д.
                  Но тогда просто составляются новые планы, более или менее долгосрочные.
                  Можно поспорить в стиле «запланировали отдать в музыкальную школу, а ребенок захотел на физмат».
                  Но это издержки планирования — все равно какое-то долгосрочное планирование есть.
                  А главное — это сильно отличается от подхода «родили и родили, фиг знает, что будет через год» :)
                  Правильно выращенный бизнес будет кормить его владельца долгие годы.
                  С этой точки зрения стоит делать наметки на то, что будет через год.
                  Ну и подход «Сегодня релизим и продаем! И пофиг, что будет потом» имеет высокие риски в будущем.
                  Я бы назвал такой подход неприемлемым.
                  Но у каждого свое видение, т.е. дело в людях)
                    –1
                    Это важно: НЕ «составляются новые планы», а корректируются существующие планы.

                    Изначальный «план» ДОЛЖЕН составляться на основании четко проработанного и известного Жизненного цикла человека продукта.
                    Вероятность изменения содержания и последовательности этапов такого цикла весьма мало.

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

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

            0
            Цена надежности – это погоня за предельной простотой. Такая цена по карману не каждому богатому
            Сэр Энтони Хоар, 1980.

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

            Э. Дейкстра, 1985 год.

            30 лет почти прошло, а воз и ныне там.
              +6
              Есть и обратная сторона медали. 8 лет я занимался разработкой: писал код, администрировал сервера и всякое такое, что программисты делают. Сейчас я занимаюсь управлением и думаю, что корень проблемы в том, что большинству программистов вообще по барабану выйдет их продукт в продакшн или нет, им просто нравится писать код, а будет он работать, как его поддерживать, это другая история.
                –2
                Потому что это не задача программиста — «выводить в продакшн», очевидно. Им пофигу, вы им платите, они пилят. А на высокоморальные ценности, которые нужны компании, а не лично ему — ему наплевать. Для этого есть вы — управленец, и это полнолстью ваша вина.
                  +2
                  • В чем именно моя вина?
                  • Так, я плачу и хочу получить определенный результат, так? Или я могу платить вечно, чтобы пилили? Пойду полью свое дерево, на котором растут деньги
                    0
                    Ваша вина в том, что товар не выведен на рынок. А вы приходите к программистам и кричите — до сих пор не запилили, сколько можно? Уже 6 миллионов потратили, а результата 0. А задачи они себе сами придумывают? А решают тот необходимый для вывода в продакшн функционал тоже они, сроки контроллируют? Нет, вы.
                      +6
                      А где я написал, что я кричу «сколько мы потратили и какой результат»? Я немного отличаюсь от сферического менеджера в вакууме тем, что я могу самостоятельно написать 100% кода, который требуется в моей работе. Вот про такое отношение как ваше я и говорил в первом комментарии. Для вас бабло растет на деревьях.
                  +7
                  Не однократно слышал эту версию от управленцев.
                  Но, есть еще и такое мнение:
                  «Задачи решаются так как они ставятся»

                  А в большинстве ситуаций, которые я видел, программистам именно так задачи ставятся.
                  Что-то вроде «Сделайте что нибудь, пофиг что и как, лишь бы завтра страничку в интернете можно было увидеть».
                  Как только начинаешь объяснять все тонкости, что это не просто «страничка в интернете», что это надо проектировать, разрабатывать, выводить в продакшен, а потом поддерживать и т.д. На тебя управленец смотрит большими глазами и спрашивает «а нафига тратить на это время/деньги, там же просто пару страничек в инете показать? Потом, если что, все сделаем как надо». Но понятное дело, что далеко не пару страничек, а это самое «если что» никогда не ставится в планы и никогда в реале не исполняется.
                  А потом приходит череда разборок и естественно все теже управленцы, которые не так давно спрашивали «а нафига тратить на это время/деньги», точно так же не моргнув глазом спрашивают «а почему не сделали?».
                  И потом рассказывают (извините, ничего личного к вам, просто мой жизненный опыт) про то, что программстам все пофиг…

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

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

                          P.S. я продолжаю ревьюировать, а иногда и писать код, администрировать сервера и делать всякое такое почти ежедневно и у меня возникает законный вопрос, почему мне не нужны тепличные условия и я как-то могу писать код в перерывах между скайпом и телефонными звонками, а вот «творческие» — не, не могут.
                            +1
                            Смею вас разочаровать, конкуренция в этой сфере усилится… только между работодателями. На Западе уже как только не заманивают людей, чуть ли не в пионерские лагери офисы превращают, дают неограниченный отпуск (и даже обязывают брать отпуск! www.paperplanes.de/2014/12/10/from-open-to-minimum-vacation-policy.html). А у нас хотят за зарплату таксиста нанять гуру чтобы сутками над кодом работал.
                              0
                              Я работал «на западе». С бельгийцами и с американцами, если быть точным. Если бы не врожденное мнение западных европейцев, что восточнее Польши живут говорящие обезьяны, они бы все в аутсорс вынесли. Не надо приводить в пример гугл — они монополисты. Я говорю про «специалистов» гораздо более скромной компетенции, чем те, что работаю в гугле.

                              Ну про какую зарплату таксиста вы говорите? Не нравится рынок в Воронеже — езжайте в Москву или выучите английский и работайте на «заграницу», уверяю вас, если вы «гуру», то за полгода спокойно выйдете на доход от $2500 в месяц, работая на американцев.

                              Но «за бугром» принято «отвечать за базар» и их я «пилил, но меня отвлекали» не устроит, особенно американцев.
                                0
                                Про зарплату всё просто. Откройте glassdoor и посмотрите. Ещё можно по hh.ru полазать, «чиста поржать».
                    +6
                    brewerof я был и нахожусь с обеих сторон одновременно. Я могу лишь рекомендовать посмотреть с другой стороны. Оттуда видно, что бизнес платит зарплату, что не всегда есть возможность делать долго и качественно. Что иногда выгоднее потом починить или сделать это в процессе, чем медленно довести всё до ума. Потому что, пока вы доводите до ума вам нужна зарплата и одновременно, продукт не выпущен и не приносит денег. Т.е. получается двойной минус. Там, с той стороны, много своих задач и именно эта сторона кормит нас инженеров.

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

                      Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, 'not far.' Yet so-called software engineers often practice their art with little or no idea of the mathematical underpinnings of what they are doing. And then we wonder why software is notorious for being delivered late and full of bugs, while other engineers routinely deliver finished bridges, automobiles, electrical appliances, etc., on time and with only minor defects.

                      (Martin Newell, Adobe Fellow)
                        +1
                        В том-то и дело, что 99% фирм не нужен софт, который будет работать десятилетия, потому, что он устареет уже через год, зато им нужна быстрая отдача и минимум вложений.
                          +2
                          Вот и получается, что проектирование моста — долгий и кропотливый процесс, который может занимать даже больше времени, чем его постройка. А об архитектуре приложения задумываются лишь после того как оно уже отбило вложения и «чё-то как-то багов много» и «надо бы ускориться». И тогда нанимают «сеньёров», рассчитывая, что они, как профессионалы, доведут до ума малой кровью. Но правда в том, что никакой малой кровью деревянный мост на подпорках не превратить в железный многотоннажный. А для превращения дерева в металл даже алхимикам нужно много крови.
                            0
                            Мост не меняется. А приложение постоянно расширяют, меняют, оно живёт, как организм. Болеет, выздоравливает, растёт и погибает. Вы можете спроектировать монолит за несколько лет или вырастить его из маленького приложения, которое хоть как-то, но уже будет приносить пользу и экономить время.
                              0
                              Без чёрной магии вы не вырастите из деревянного моста железный :-)
                                0
                                Я о некорректности сравнения неживого с живым. Да и мосты тоже чинят, заменяют, расширяют.
                                  0
                                  А я об архитектуре. Вы не сможете плавно изменить процедурную парадигму на функциональную.
                          +1
                          Уважаемый krasko, в последних двух абзацах я не написал ничего, что относится к этой замечательной цитате.

                          Музыкант не должен играть без нот, а инженер работать
                          «with little or no idea of the mathematical underpinnings of what they are doing»
                          Но! Математика для инженерии и инженерия для математики — это две большие разницы. Я видел senior'ов с «solid mathematical background», но не знающих, что код метода не должен быть длиной 342 строки.

                          Если есть знакомые/друзья которые учились например в немецких технических ВУЗах, поитересуйтесь как, когда и в какой форме там дается математика.
                            +1
                            Про то, что код метода не должен быть длиной 342 строки, инженеру сообщат на первой работе, пока он будет джуниором. Там же он познакомится ещё с тысячей других технических деталей, с которыми знакомиться там и место.

                            Что там у немцев знаю плохо, зато знаю, что наши инженеры востребованы по всему миру, причём часто потому, что с математикой у них более-менее, в отличие от многих их западных коллег. Но инженерия уходит вперёд, появляются новые концепции, многие из которых имеют сильные математические основания, и которые нужно применять с умом и понимать. Математика также развивается, а вот вузы наши отстают — это повод переработать существующие курсы и выкинуть кучу хлама (взятие 100 производных и интегралов руками на 1 курсе), добавить больше содержательной математики, полезной программисту (дискретная математика, алгоритмы, теория типов). Это проблема вузов, а не математики, что в них учат не тому.

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

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

                            Что такое математика для инженеров я понял, в вот что такое инженерия для математики я вообще плохо себе представляю (написание систем компьютерной алгебры?).
                              +1
                              Код метода в 342 строки — это очевидное нарушение одного из базовых принципов проектирования ПО, single responsibility principle. И это не «техническая деталь», с которой «знакомиться там и место», а то, что превратит код проекта в «большой ком грязи», ну или «спагетти-код», кому как нравится.

                              Базовые знания о проектировании ПО должны разумеется закладываться в ВУЗе, на профильных дисциплинах — ООП, технологии разработки ПО, контруирование ПО и тд
                                +1
                                Когда джуниор первый раз напишет спагетти-код, а ещё лучше, когда он попытается разобраться в чужом спагетти-коде и поймёт, что так делать нельзя, тогда и придёт понимание этого single responsibility principle. Для этого не обязательно учиться в вузе вообще. Это вещи, с одной стороны, лежащие на поверхности, с другой — приходящие только с опытом. Для лучшего понимания таких вещей, для анализа примеров, есть книги от признанных авторитетов разработки, которые разработчик должен прочитать в дополнение к вузовской программе по собственному желанию. В вузе можно дать пару таких курсов в семестре перед дипломом (чтобы студенты просто знали, куда глядеть; достаточно, возможно, просто нескольких лекций), но базировать всё обучение на них ни в коем случае нельзя.

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

                                  -Участвовать в проведении научных исследований (экспериментов, наблюдений и количественных измерений) программных продуктов, проектов, процессов, методов и инструментов программной инженерии
                                  -Заниматься построением моделей программных проектов и программных продуктов с использованием инструментальных средств компьютерного моделирования
                                  -Составлять описания проводимых исследований, готовить данные для составления обзоров и отчетов
                                  -Заниматься сбором и анализом требований заказчика к программному продукту
                                  -Помогать заказчику в оценке и выборе вариантов программного обеспечения
                                  -Участвовать в составлении коммерческого предложения заказчику, готовить презентации и согласовывать пакет договорных документов
                                  -Проектировать компоненты программного продукта в объеме, необходимом для их конструирования в рамках поставленного задания
                                  -Создавать компоненты программного обеспечения (кодирование, отладка, модульное и интеграционное тестирование)
                                  -Выполнять измерения и рефакторинг кода в соответствии с планом
                                  -Заниматься разработкой тестового окружения и созданием тестовых сценариев
                                  -Разрабатывать и оформлять эскизную, техническую и рабочую проектную документацию
                                  -Осваивать и применять средства автоматизированного проектирования, разработки, тестирования и сопровождения программного обеспечения
                                  -Осваивать и применять методы и инструментальные средства управления инженерной деятельностью и процессами жизненного цикла программного обеспечения
                                  -Осуществлять контроль, оценку и обеспечение качества программной продукции
                                  -Обеспечивать соответствие разрабатываемого программного обеспечения и технической документации российским и международным стандартам, техническим условиям, нормативным документам и стандартам предприятия
                                  -Участвовать в процессах разработки программного обеспечения
                                  -Участвовать в создании технической документации по результатам выполнения работ
                                  -Проводить обучение и аттестацию пользователей программных систем
                                  -Участвовать в разработке методик обучения технического персонала и пособий по применению программных систем
                                  -Участвовать в составлении технической документации (графиков работ, инструкций, планов, смет, заявок на материалы, оборудование, программное обеспечение)
                                  -Планировать и координировать работу по настройке и сопровождению программного продукта
                                  -Организовывать работу малых коллективов исполнителей программного проекта
                                  -Вводить в эксплуатацию программное обеспечение (осуществлять инсталляцию, настраивать параметры, адаптировать, администрировать)
                                  -Осуществлять профилактическое и корректирующее сопровождение программного продукта в процессе эксплуатации
                                  -Обучать и консультировать пользователей по работе с программной системой

                                  Чем быдлокодер, получившийся в результате неких «курсов», отличается от инженера по разработке ПО, можно попытаться понять например тут.
                                    0
                                    Просто к вашему спору реальный случай:
                                    На одном из проектов к нам пришла девочка с профильным красным дипломом. И как-то на экскурсии по конторке, показал ей одного парня, который без образования вообще и уточнил, что если хоть один из преподов одного ВУЗа, работающих у нас решит задачку быстрее и лучше его, то куплю шляпу, что-бы снять. По результатам задачи, девочка сделала выводы и больше ни когда не заикалась про свой диплом.

                                    Но это не значит, что всем надо бросать учёбу!
                          +1
                          Ну в общем-то как раз cейсчас пишу статью «freelance — you're doing it wrong», в рамках которой описываю основные организационные и управленческие проблемы с которыми мне приходилось сталкиваться.

                          Если кратко, то это
                          1. Дилетанство и предрассудки — заказчики/руководство не способны учится даже на своих собственных ошибках
                          2. Ригидность — не способны адаптироваться к новым условиям
                          3. Желание сэкономить, часто на организации труда — напрочь убивают поддержку
                          4. Неспособность адекватно оценивать риски. Все риски делегируют посредникам — убивают масштабирование.
                          5. Личные психологические расстройства и компенсаторные процессы:
                            • Я хочу быть самым умным и/или самым главным...
                            • Я хочу подчинятся...

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

                          Я могу продолжать, это неполный список.

                          Опять же примитивное гнилое постсоветское общество с протёртыми книжными проблемами передача которых с поколения в поколение ещё и поддерживается родственниками и окружением. Та-да…
                            0
                            Во многом с Вами согласен на все сто процентов. Только я подобный вопрос люблю рассматривать на примере автомобилестроения, где итоговой фразой всегда выходит: «раньше автомобили делали инженеры, сейчас маркетологи». Но пишу по другому вопросу, точнее уточнению. Вы уверены, что в образовании корень проблем? Дело в том, что я бывал на многих предприятиях и везде одно и то-же — разные цели у заказчика и исполнителя. Ну не нужен заказчику супер-мупер красивый код, ему надо просто что-бы выполнялась работа и она превращалась в деньги. Заказчик не виноват, что он любит деньги, он просто как и все — человек.
                              +1
                              Красота кода — это не главный критерий, код не картина и не женщина, главный критерий — эффективность. Красота это производная эффективности скорее…

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

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

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

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

                                0
                                Вот прям всё кратко и очень точно. Многим этого не хватает, равно как и мне. Но я опять немного про другое, а именно про последний тезис:
                                Только заказчик/менеджмент проекта зачастую воспринимает эти практики, как какие-то глупые, ненужные и совершенно излишние вещи.

                                Здесь я в корне не согласен, потому-что сам лично был в составе рабочих групп по выбору различных методик. Уверяю, глупыми их не считали, но накладывая готовые методики на наши реалии получали часто отрицательный результат. Самое плохое, когда этот результат получали практически, страдал и заказчик и мы как исполнители. Основные методики по проектной деятельности брали из опыта таких мировых гигантов, как кока-кола, ай-би-эм и т.д. Активно использовали итил и всё сопуствующее. При этом в нашем коллективе в качестве консультантов были довольно-таки умные преподаватели одного ВУЗа, зарекомендовавшие себя во многих сферах, смежных с аналитиками.
                                В общем, как-бы всё не было умно и правильно, с точки зрения методологии, в реальности, увы, надо было делать упор на другие методики, которые по мнению многих топорные и не эффективные.
                                В общем, если у Вас есть конкретная мысль как правильно делать, было бы интересно её услышать (если это возможно). Просто идея без детализации
                                  0
                                  >если у Вас есть конкретная мысль как правильно делать, было бы интересно её услышать…

                                  Из своего опыта могу сказать, что идея одна и она отлично работает — «всегда надо смотреть по ситуации».
                                  Для меня все эти методики синонимы здравого смысла.
                                  Если очень коротко, то опыт кока-колы отлично подойдет если вы строите полный аналог бизнеса кока колы, опыт ай-би-эм если вы строите аналогичный бизнес и т.д… Но даже в этом случае нет гарантий, что эти методики подойдут людям которые у вас в команде. В общем отношусь к опыту других компаний по принципу «Сказка ложь, да в ней намёк...».
                                  Просто видел не один раз, когда брали опыт огромной компании и пытались «натянуть» на маленькую компанию. Я это обычно называю «выключить мозг». Тут дело даже не в самом размере, а в том что организация работы 5 человек и 100 человек сильно отличается.
                                  К тому же менталитет людей сильно отличается. Да и цели и задачи могут отличаться.
                                  Поэтому всегда надо смотерть по ситуации. При чем большую часть внимания надо уделить людям, ибо они в конечном итоге решают, а не методики.
                                  Как пример, участвовал в одном проекте, где как такового планирования/проектирования не было вообще. Тогда еще не было этого хайпа во круг аджайла и прочих скрамов. Но команда была на столько удачной, что они самоорганизовывались без проблем. Короткая летучка, определяли следующий шаг и впреред.
                                    0
                                    Нуууууу… Знаете, во многом Вы правы, кроме уверенности в стопроцентном успехе. Наскоком, скорее всего, невозможно ни чего сделать вообще, кроме как случайно. Понимаете, опыт гигантов, это труд многих человеколет. Чаще всего люди не приветствующие этот опыт, изобретают велосипед. Например, опыт кока-колы на фоне пепси-колы, говорит, что нельзя кидаться в крайности, ведь одна компания сделала упор на рекламу, забыв всё остальное, вторая на отладку бизнес-процессов, забыв про рекламу. результаты можно наблюдать даже школьнику — газельки процветают, зилы почти мертвы.
                                    В общем, я всё-таки не соглашусь с Вами и поддержу мнение многих серьёзных компаний, которые всё-таки отдают предпочтение каким-либо методикам. Но подтверждаю, мы тоже сначала пытались решать всё наскоком, пока не подошли эволюционно к тому, что надо изучать методики.
                                      0
                                      Собственно никто «наскоком» ничего не решает, откуда вы это вообще взяли?
                                      Просто мы не ищем «серебряную пулю», которая даст какое-то универсальное правильное решение.
                                      Всегда смотрим по ситуации.
                                      Проекты разные, люди разные, цели и задачи разные… откуда тут возьмется единственно правильное решение?
                                        0
                                        Например, декомпозиция и синтез бизнес-процессов, например, по IDEF0, сберегает массу времени на самых разных проектах.
                                    0
                                    У меня нет конкретных мыслей как все правильно делать, если нет конкретной вводной.

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

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

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

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

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

                                      Немного отвлекусь в пустословие
                                      Дьявол в мелочах, как известно H2O и H2SO4 отличаются только одним элементом

                                      Предлагаю в следующий раз сравнивать две известнейшие химические формулы: С и С (графит и алмаз)

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

                                      Другие за то знают. Мы брали чужой опыт, который давно уже проработан донельзя. Стандарты итила многое дают, стандарт IDEF-ов многое дополняет, ну а UML прекрасно всё показывает. Правда этот список огромный и на разных уровнях абстракций, он выглядит по разному, но всё равно он конечен и более-менее формализуем.
                                      Например, одна из стадий проектной работы, это внедрение итерационного подхода к решению и корректировки пути достижения к цели. Всё ни чего, всё красиво, но из-за специфики итерационности мы «размазываем» время выполнения проекта, рассогласуем с другими направлениями, сильно увеличиваем риски, которые ни кто не хочет на себя брать, ну и в целом скатываемся в плохую ямку. Но и без этой технологии нельзя, потому что общение заказчика с исполнителем несёт всегда незаконченный характер и если отказаться от итеррационности, то мгновенно получим провал в виду неудовлетворённости заказчика.
                                      В общем, там всё сложно. Можно разложить по полочкам, но (ёлыпалы) не всё так просто как кажется
                                0
                                Образование нужно скорее не в сфере программной инженерии, а в сфере менеджмента. Менеджеры (на стороне бизнеса) должны понимать чем хороший (эффективный) заказчик ИТ-решений отличается от чудака который может только истерики устраивать и корчить из себя требовательного начальника.
                                  0
                                  Насчет того что «Инженерная деятельность — это служанка бизнеса». Действительно, наверняка многие руководители рассуждают в таком духе: вот я такой умный и красивый, разбогател на торговле шпингалетами, у меня есть секретарша, водитель, штат грузчиков, менеджеры по продажам — я их всех успешно дрессирую. Давайте я еще возьму себе программистов и тоже буду их дрессировать.
                                  Тут, на мой взгляд, вопрос в том что команда разработчиков — это для заказчика в большей степени партнеры по бизнесу. Их нельзя дрессировать. Их надо аккуратно выбирать (уметь отличать хороших от плохих — что само по себе крайне сложно) и выстраивать партнерские отношения, считаться с мнениями и интересами. А культура кооперации и договороспособности в среднем по стране, мягко говоря, не на очень высоком уровне. Это не только проблема ИТ.
                                    0
                                    Партнеры по бизнесу они в тот момент, когда готовы взять риски, в т.ч. финансовые на себя. Остальное — лирика. Вы безусловно правы в том, что методы управления менеджерами по продажам, секретаршами, программистами и танцорами — разные.
                                    +6
                                    самое обидное, что это:
                                    Результат – баги, выпорхнувшие в релиз из-за такого отношения к QA, наносят такой репутационный и финансовый ущерб компании, по сравнению с которыми затраты на постановку реально эффективного процесса работы с качеством продукта покажутся мизерными.
                                    не так.
                                    Бизнесс постоянно покупает глючное страшное убогое говно ПО, просто потому, что его уже несколько десятилетий пилит фирма с репутацией.
                                    И даже если после следующего обновления для использования их ПО придётся вставлять анальный зонд — это никак не изменит репутацию фирмы-разработчика и не повлияет на продажи.

                                    Пару примеров:
                                    ПО для управления проектами стоит десятки тысяч евро. Когда я, как сисадмин попросил их прислать msi что бы установить на ПК пользователей централизовано и автоматически. Мне прислали ответ: извините, но человек который умел делать msi уволился.
                                    Или официальный софт для СКД при любом действии с пользователем выдает TB:user error ничего не записывая в логи. Связался с тех поддержкой… ответ: Не обращайте внимания — это нормально. Никаких патчей разумеется не выслали. Этой версии уже несколько месяцев, и когда будет следующий релиз неизвестно.
                                      +1
                                      Возможно тут дело просто в монополизации сегмента рынка ПО и, как следствие, зашкаливающем «борзометре» у монополиста.
                                      +1
                                      Мне кажется, что проблема тут в отсутствии взаимопонимания, даже скорее взаимопроникновения знаний. Менеджер, работающий в контакте с командой программистов, обязательно должен обладать неким базовым набором знаний в программной инженерии, иначе он не сможет понять причины возникновения тех рисков, о которых ему будут говорить разработчики. А значит, он от них просто отмахнется. С другой стороны, разработчики должны понимать, для каких целей они делают ПО, кто и как им будет пользоваться, и в какую сторону оно предположительно будет развиваться (если вообще будет).
                                      В конечном итоге, менеджер и команда разработчиков должны ДОГОВАРИВАТЬСЯ друг с другом, и не ударяться в крайности, а принимать компромиссные решения, которые позволят не только снять сливки сейчас, но и продолжить это делать в течении длительного времени с минимальными затратами.
                                        +1
                                        Душевно. Относится не только к России; у нас в Заливной Области та же фигня. Так что валить на особенности русского образования, бизнеса, менталитета вряд ли имеет смысл. И китайцы такие же, и индийцы такие же, и местные такие же, и европейцы едут такие же; различается только внешний стиль.

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

                                        С другой стороны, у менеджеров в бизнесе горизонт — полгода, а то и пара недель. Ну и даже если нет, найти причину прищучить инженеров («это ваши ошибки» (которые вы допустили, слушаясь меня)), чтобы слушались лучше.
                                          –1
                                          А в чём собственно проблема? Заказчик/бизнес дурак? — Ну и пусть страдает и умирает. Люди платят за плохой софт? — Это их выбор. Бедному инженеру программисту не нравится делать плохой софт? — Да делай хороший и продавай, не можешь — делай то что тебе говорят и не ной. И да — это бизнес, а не научная деятельность.
                                          Я думаю стоит изменить отношение к своей работе, к работе приложений, к людям. Вы просто делаете то что от вас требуют и получаете за это деньги, всё. Всё остальное не ваше дело пока вам платят. В свободное от работы время можете писать и проектировать всё что вам угодно. Программист вообще всегда в шоколаде, это у менеджеров и руководителей голова должна болеть.
                                            +2
                                            Мой коллега-программист, когда менеджер стал учить его жизни, так, вполголоса сказал — ну, типа, я менеджеров уже с десяток тут повидал, а я здесь двадцать лет код пишу.
                                              +2
                                              Да… ну прямо бальзам на душу.
                                              Понимаю, разделяю, почти во всем с Вами (с автором статьи) согласен.

                                              Но вот тут:
                                              надеюсь, больше людей будут приходить из реальной разработки в качестве преподавателей в ВУЗы

                                              есть неопределенность, по крайней мере у меня.

                                              Неоднократно «приходил» с этими целями (какое-то время работал в университете, потом просто читал тематические лекции по приглашению коллег).
                                              Но аудитория не всегда готова к тому, о чем я пытаюсь рассказать. Ты им про архитектурные решения, а они ничего больше 30 строк (кода) в своей жизни не писали. Тут нужна систематическая работа. Что бы все учебные курсы были правильно логически выстроены, и читались со 100%-ной отдачей опытными людьми. Как бы, сферический конь в вакууме получается.

                                              Еще один момент. Ловлю себя на мысли, что вот я рассказываю студентам о том как надо программировать (по моему мнению), прихожу на работу, а там все как Вы описываете, и бизнес, и сроки. Да… еще есть коллеги-программисты, для которых тоже, иногда, не хватает аргументов объяснить, что «так делать в репозиторий не хорошо» (если по-мягче выразиться). Ведь неопределенные фразы: «лучше», «более гибко», «легче поддерживать» вызывают такие же блестящие ответы: «но так тоже работает», «а зачем нам гибкость, надо быстро сделать», «а мы поддерживать не собираемся» соответственно. Так зачем я студентам голову то морочу? Может пусть программируют как умеют?

                                              Но силы бороться пока есть :)
                                                +1
                                                По теме статьи можно сказать одной фразой:

                                                Культура бизнеса (читай «делания денег») определяет культуру производства,
                                                и, следовательно, существенно влияет на то, что производится для нашего потребления.

                                                … ну, и чтобы печально замкнуть цикл процитирую: "мы есть то, что потребляем".

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

                                                Самое читаемое