Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Если уже говорить о «целой индустрии», то не надо путать понятия программист с точки зрения обывателя, и разработка программного обеспечения, какой она должна быть. Статья на которую Вы ссылаетесь, не о разработке вообще, она о поделках «знакомых программистов». И в этом качестве она во многом точно характеризует положение вещей. Проблемы индустрии здесь нет, спрос рождает предложение(в данном случае спрос на дешевые решения)
А вообще — не давайте программистам общаться с заказчиком о деньгах и сроках, и все будет хорошо.
А вообще — не давайте программистам общаться с заказчиком о деньгах и сроках, и все будет хорошо.
Полностью согласен с вашим мнением во всём, кроме последнего пункта. Совсем избежать оценки сроков и чтения ахинеи заказчика программистом не представляется возможным, как не пытаться — всё равно не поместишь программиста в идеальный приятный хрустальный шарик. Можно лишь сделать всё, чтобы минимизировать нежелательные влияния.
"Тут вообще нечего обсуждать, производительность должна быть константой, основная задача руководителя – следить за этим"
И в чем же мерять эту самую «производительность»? Лучшие умы годами бьются над этим, изобретают всевозможные метрики, а воз и ныне там. Проблема разработки ПО как «инженерной науки» как раз и состоит в том, что тут нет прямого аналога «скорость * время = расстояние». Токарь третьего разряда выточит штуцер за час, а второго — за полтора. А что является «штуцером» для программиста? Сортировка пузырьком? Но никому не нужны 1000 одинаковых процедур сортировки (в отличие от 1000 штуцеров). Каждая строчка каждого программиста — уникальна (даже копи-паста не помогает, а вредит). И каждая система в конечном итоге уникальна, пусть даже многие из них называются похоже.
Перед началом стройки мы можем представить себе мост, или здание, спроектировать его с хорошей точностью, разбить на узлы, посчитать кол-во кирпича, песка и ж/б свай и получить примерную смету по времени и цене. А кто может себе с подобной детализацией представить программный продукт до начала его разработки? Тут я прежде всего говорю не о функциональности, а о собственно создаваемом программистами артефакте — программном коде. Сколько там будет строк, классов, этих самых функциональных точек?
«Проклятая неизвестность». Перед которой пасуют все методики.
Поэтому мы нанимаем опытных программистов — и всё равно идем по большей части наугад, постоянно корректируя начальную оценку.
И в чем же мерять эту самую «производительность»? Лучшие умы годами бьются над этим, изобретают всевозможные метрики, а воз и ныне там. Проблема разработки ПО как «инженерной науки» как раз и состоит в том, что тут нет прямого аналога «скорость * время = расстояние». Токарь третьего разряда выточит штуцер за час, а второго — за полтора. А что является «штуцером» для программиста? Сортировка пузырьком? Но никому не нужны 1000 одинаковых процедур сортировки (в отличие от 1000 штуцеров). Каждая строчка каждого программиста — уникальна (даже копи-паста не помогает, а вредит). И каждая система в конечном итоге уникальна, пусть даже многие из них называются похоже.
Перед началом стройки мы можем представить себе мост, или здание, спроектировать его с хорошей точностью, разбить на узлы, посчитать кол-во кирпича, песка и ж/б свай и получить примерную смету по времени и цене. А кто может себе с подобной детализацией представить программный продукт до начала его разработки? Тут я прежде всего говорю не о функциональности, а о собственно создаваемом программистами артефакте — программном коде. Сколько там будет строк, классов, этих самых функциональных точек?
«Проклятая неизвестность». Перед которой пасуют все методики.
Поэтому мы нанимаем опытных программистов — и всё равно идем по большей части наугад, постоянно корректируя начальную оценку.
Если взять программиста-фрилансера, то ошибка в прогнозах — это только недостаток опыта. Если же взять программиста из штата какой либо средней или крупной компании, то он не должен задумываться о прогнозах времени разработки как таковых, а тем более ему не надо изучать методологии прогнозирования))
Все это должен делать PM достаточной квалификации, согласовывая на финальной стадии с SeniorPM либо с техническим директором.
Все это должен делать PM достаточной квалификации, согласовывая на финальной стадии с SeniorPM либо с техническим директором.
«ПМ достаточной квалификации» — кто это, если не «бывший программист»? Иначе его «оценка» будет просто высосана из пальца продиктована чем угодно, только не реальной действительностью.
Если ПМ не из «бывших», то он спрашивает реальную оценку у тимлида. А потом уже её «согласовывает» по инстанциям. Желательно в интересах команды.
Если ПМ не из «бывших», то он спрашивает реальную оценку у тимлида. А потом уже её «согласовывает» по инстанциям. Желательно в интересах команды.
Исследования. Данная причина возникает только из-за отсутствия опыта или нехватки знаний. А еще появление такой причины говорит об отсутствии этапа проектирования, вот и приходится принимать проектные решения и заниматься исследованиями в процессе кодирования, естественно это увеличивает сроки разработки. А отсутствие этапа проектирования подтверждает отсутствие опыта у разработчика. Вывод: повышать опыт и квалификацию.
Как вы сразу с плеча-то рубите. Присутствие этапа проектирования это, конечно, хорошо. Но у разработки ПО, в отличии от многих других дисциплин, есть одна неприятная отличительная особенность — мы практически никогда ничего не делаем повторно. Потому как нулевая цена копирования. Поэтому если уж встала задача разработки — значит с высокой степенью вероятности мы будем это делать в первый раз. Потому как если это уже делали — мы или еще кто-то и исходники открыты — то нам нет необходимости разрабатывать, мы используем уже готовое.
Современные информационные системы сложны. Причем даже не качественно, ядреный реактор посложнее будет, а количественно. От процессора с памятью до HTML кода — десятки слоев абстракции и много десятков разных технологий. Специалистов, которые знают широкий спектр технологий мало, в основном разработчики довольно узкоспециализированы.
И вот когда разработчик с узкой специализацией начинает решать новую задачу, возникают риски. Потому как все используемые технологии он не знает (трудно одновременно разбираться в том как работает кэш процессора, барьеры памяти в никсах, движок апача, интерпретатор PHP, интерпретатор HTML, интерпретатор HTML, локи в базе данных и при этом еще хорошо программировать на основе современных трендов. Такие люди, конечно, есть — но их мало). И те области, которые он не знает и с которыми до этого не сталкивался начинают преподносить сюрпризы.
Например — проектировали мы, тестировали, даже опытный образец сделали. Все хорошо. Назначили сроки. А в середине разработки неожиданно выяснилось, что на наших данных с нашими нагрузками репликация в каком-нибудь PostgreSQL не работает. Просто не работает. Связались с разработчиками, заплатили деньги за поддержку, те посмотрели и говорят — «извини, мужик, наша архитектура не рассчитана на такой use case, косяк.». Это нигде не написано, это нельзя предсказать, это никак нельзя учесть на этапе проектирования или проверить на простых тестах. И такое случается регулярно.
Если делать одно и тоже, например типовой сайт, то сроки предсказываются очень точно. Проблема в том, что термин «делать» здесь малоприменим — как уже говорилось, для решения типовых задач нет необходимости что-то разрабатывать — достаточно копировать уже готовые типовые конструкции. А когда мы по каким-то причинам не можем применить типовые конструкции и начинаем что-то разрабатывать — то мы часто вынуждены использовать более широкий спектр технологий чем тот, в котором мы хорошо разбираемся. И даже если заморозить стэк технологий, как делают в некоторых организациях, то это все равно не помогает — потому как технологии регулярно обновляются, и буквально через пару лет оказывается что наш замороженный набор устарел и мы не можем применять его на актуальном железе / операционках / инфраструктуре. Технологии развиваются достаточно динамично, и мы вынуждены раз за разом использовать что-то новое, что до этого не использовали.
Давайте начнём с того, что как правило проект делает не один программист. И тут возникает глупый вопрос — а кто сроки то оценивает? Вы уж извините, но в начале проекта невозможно (и даже крайне глупо) планировать кто из программистов какую задачу будет делать — всем понятно, что будет некий обмен задачами. Будут новые задачи появляться, в конце концов. И тут то мы и видим, что не один программист не в силах оценить сроки правильно. Т.к. ориентируется по себе, а не по товарищам в целом.
Поэтому, кстати, во многих методологиях принято рассматривать не программистов в отдельности, а команду, как боевую единицу. И вот её статистическая производительность, особенно на длительном этапе времени — довольно постоянна.
Так что заводите себе руководителей группы, знакомых с методологиями управления и оценки сроков, и прекращайте спрашивать оценку сроков у программистов. Я, кстати, не слышал о ситуации, когда о сроках строительства спрашивали бы у собственно рядовых строителей, а не руководителей.
Я уж молчу, что оценка разработки и производства — это абсолютно разные вещи.
Поэтому, кстати, во многих методологиях принято рассматривать не программистов в отдельности, а команду, как боевую единицу. И вот её статистическая производительность, особенно на длительном этапе времени — довольно постоянна.
Так что заводите себе руководителей группы, знакомых с методологиями управления и оценки сроков, и прекращайте спрашивать оценку сроков у программистов. Я, кстати, не слышал о ситуации, когда о сроках строительства спрашивали бы у собственно рядовых строителей, а не руководителей.
Я уж молчу, что оценка разработки и производства — это абсолютно разные вещи.
Чтобы в голову не приходили такие мысли, какая вынесена в заголовок, почитайте на досуге книгу А. Р. Лурии «Язык и сознание». Там приводятся очень занимательные данные, которые были получены в процессе изучения интеллектуальных способностей людей в Средней Азии в 1930-1931. Данные эти касаются первобытных мыслительных способностей, которые не выходят за рамки сравнения ситуации со своим или известным чужим опытом и более совершенных мыслительных способностей, основанных на абстрактном мышлении.
Опыт, как основа эмпирического мышления, позволяет повторять (в разной степени обдуманно) действия, которые ранее показали себя эффективными в аналогичной ситуации. Но если ситуация носит иной характер, самый богатый опыт не позволит решить совершенно ничего — в нем не найдется готового ответа. Только абстрактное, теоретическое мышление позволяет строить гипотезы на основе изучения тенденций, проверять их и делать выводы о совершенно новых ситуациях (которые составляют большинство, если разработчики не клепают однотипные проекты по шаблону).
Опыт, как основа эмпирического мышления, позволяет повторять (в разной степени обдуманно) действия, которые ранее показали себя эффективными в аналогичной ситуации. Но если ситуация носит иной характер, самый богатый опыт не позволит решить совершенно ничего — в нем не найдется готового ответа. Только абстрактное, теоретическое мышление позволяет строить гипотезы на основе изучения тенденций, проверять их и делать выводы о совершенно новых ситуациях (которые составляют большинство, если разработчики не клепают однотипные проекты по шаблону).
Из прочитанных комментариев я сделал вывод, что достаточно часто оценку времени дает один эксперт (руководитель, PM и т.д.), что не совсем правильно. Именно это я и хотел сказать в статье – нужны опыт и знание методик. Если у вас один разработчик и он же эксперт, с этой ситуацией все понятно, но если имеется более двух экспертов, недостаточно получить среднее значение их оценок, имеет смысл применить одну из методик экспертного оценивания (позволяющую, например, учесть веса экспертов), это позволит повысить точность оценки. Даже если у вас крайний случай нетиповой задачи, необходимо подойти к оценке научно-обоснованно, можно воспользоваться, например, методом PERT.
В общем, с энтропией надо бороться, а не уповать на нее. А инструмент для этого – опыт и знания.
Я почему-то предполагал, что основные дебаты будут вокруг методик оценки и эффективности их применения.
В общем, с энтропией надо бороться, а не уповать на нее. А инструмент для этого – опыт и знания.
Я почему-то предполагал, что основные дебаты будут вокруг методик оценки и эффективности их применения.
Мне кажется, вы просто очень жестко изложили свои мысли, которые абсолютно не соответствуют опыту многих разработчиков.
Причин много: главное — высокая уникальность каждого проекта (это отметили почти все ваши оппоненты). Второе — как правило неадекватный менеджмент (девочки после инъяза в роли аналитиков и продажников). Третье — фаза исследований и планирования обычно полностью отсутствует: заказчик покрутит пальцем у виска, если вы ему предложите оплатить полугодовалые исследования-планирования даже перед началом проекта длительностью в 5-10 лет.
Ну и на закуску: заказчик обычно хочет аналог ютьба и пинтереста за неделю и сто баксов. Может потому что платит из своего кармана (в случае машинстроения обычно или большой карман большой компании или большой карман государства), может потому что ни черта не понимает в этих ваших компьютерах.
Причин много: главное — высокая уникальность каждого проекта (это отметили почти все ваши оппоненты). Второе — как правило неадекватный менеджмент (девочки после инъяза в роли аналитиков и продажников). Третье — фаза исследований и планирования обычно полностью отсутствует: заказчик покрутит пальцем у виска, если вы ему предложите оплатить полугодовалые исследования-планирования даже перед началом проекта длительностью в 5-10 лет.
Ну и на закуску: заказчик обычно хочет аналог ютьба и пинтереста за неделю и сто баксов. Может потому что платит из своего кармана (в случае машинстроения обычно или большой карман большой компании или большой карман государства), может потому что ни черта не понимает в этих ваших компьютерах.
А не затруднит ли читателей оставить комментарий (в 2-3 строчки) о том как обстоит дело с оценкой трудоемкости в их организации?
Последний проект: ЭДО для сети гипермаркетов. Начало — декабрь, плановое окончание — апрель, срок определен бизнесом — под начало договорной кампании. Начальной оценки как таковой не было, делали на основе расплывчатого ТЗ с постоянными уточнениями по ходу дела. Прототип показали в середине февраля. Сдали первую версию в мае и сразу стали делать вторую.
Вторую версию оценивали тимлид + пара ведущих программистов на основе имеющейся кодовой базы, формальные методики не использовались, расписали на 2 части, конечный срок был определён ноябрем. В основе переделок — редактирование Экселя через вебдав. С этим было очень много проблем, технических и постановочных, поэтому первую часть сдали в марте, а вторую — только в августе.
Вторую версию оценивали тимлид + пара ведущих программистов на основе имеющейся кодовой базы, формальные методики не использовались, расписали на 2 части, конечный срок был определён ноябрем. В основе переделок — редактирование Экселя через вебдав. С этим было очень много проблем, технических и постановочных, поэтому первую часть сдали в марте, а вторую — только в августе.
А отсутствие этапа проектирования подтверждает отсутствие опыта у разработчика. Вывод: повышать опыт и квалификацию.
Наоборот. Неопытный человек в любой деятельности старается планировать перед первым шагом всё и вся. Потому что испытывает страх и понимает, что есть высокая вероятность ошибиться. Чем более опытный человек, тем меньше у него занимает времени процесс планирования. И тем больше он откладывает планирование на потом. Чтобы по мере выполнения задания иметь больше информации.
Также такой же страх перед задачами испытывают руководители проектов, не имеющие опыта в выполнении задач. Т.е. не программисты. Страх потери контроля за ситуацией заставляет их думать, что нужно всё планировать, рисуя классы, объекты и связи на картинках. Который им понятны. А код не понятен.
Желание планировать имеет психологические причины. Чем более опытный человек, тем меньше планирует. Потому что сталкивался с подобными задачами. Потому что мало существует для него неожиданно невыполнимых задач. Потому что чувствует в планировании пустую трату времени. Потому что ситуация меняется и никогда и ничто не идет по плану. При этом планы еще и ограничивают действия в измененной ситуации.
Планирование и непланирование можно сравнить, как игру в шахматы. Представим, что играют за одной доской одна группа шахматистов против другой. Шахматисты — это программисты. У них есть еще заинтересованные руководители, которые не умеют играть и правил не знают.
Расставили фигуры на доске в начальной позиции. Собралась группа. И руководитель говорит:
— Давайте обсудим, как вы собираетесь выиграть?
И начинается рисование плана. Вместо фигур рисуют квадраты и кружочки. Поле рисуют ни в коем случае не в клеточку. Руководитель ничего не хочет знать о правилах и прямом изображении игры (т.е. код он видеть не хочет). И пошло рисование.
— Если противник будет ходить этой пешкой в первый ход, то мы походим так.
— Ок. Ты, Вася, будешь двигать фигуру, когда противник походит именно этой пешкой.
Нарисовали картинку ходов до самого конца игры. конечно, не все варианты. Но есть же опыт у игроков. Они не разу не видели, чтобы конем ходили первым. Ну и т.д.
Сели за стол. Противник пошел конем.
!!! Снова консилиум. Снова перестройка всех планов. Опять по новому прорисовали хода, составили документы, согласовали, подписали.
На пятом ходе противник снова отклонился.
!!! Нет, ну он вообще афигел. Что ж такое!!! Какой-то недисциплинированный игрок! (заказчик. вечно требования меняет).
Опять консилиум. Опять в воображении и на доске выиграли битву. Снова садимся за стол. И т.д.
Непланирование, это когда люди умеют играть. И садятся и играют. Они готовы к изменяющейся ситуации. Они знают правила и схемы им рисовать ни к чему. Они понимают, что значит расположение фигур и чем отличается черная и белая клетка (ничем ))). Им не надо заниматься непродуктивной деятельностью: объяснять руководителям как будет происходить игра, не прибегая к игровой доске. И не надо давать ответ на шизофреническое убеждение руководителя, сколько ровно ходов будет длиться партия. Руководитель считает, что это самое важное в игре. И убежден, что профессионал от непрофессионала отличается только тем, сможет ли он точно предугадать количество ходов или нет.
вечное противостояние «физиков и лириков».
программисты — лирики, они не хотят планировать, они хотят весело программировать, пробуя прикольные фичи, новые фреймворки, на каждом углу рассказывая, что им для работы нужно вдохновение и «печеньки». Продолжая аналогию с шахматами — «они же умеют играть» (С) и поэтому им скучно играть похожие партии. Они могут «для лулзов» взять и пожертвовать пару пешек. Или ферзя. Или могут бесконечно выстраивать фигуры на доске красивыми рядами, называя это «рефакторингом» или «реализацией паттерна». И очень редко задаются вопросом — «А кто оплачивает банкет?» (С)
А оплачивают его серьезные дяди, которые прежде всего считают деньги и время. И им дела нет до веселых программистов, им надо знать «когда?». И они постоянно задают этот вопрос физику-ПМу. И ответ «месяца через два» или даже «скоро» их не устраивает. Им нужны цифры и проценты. Поэтому ПМ и рисует планы, схемы и графики. Переводя вдохновение программистов в скупой язык цифр. И дяди дают программистам новую банку варенья и коробку печенья.
А если не будет никакого плана — то будет не работа и результат, а анархия, все весело проведут время, завалят проект и дружно пойдут искать новую работу.
программисты — лирики, они не хотят планировать, они хотят весело программировать, пробуя прикольные фичи, новые фреймворки, на каждом углу рассказывая, что им для работы нужно вдохновение и «печеньки». Продолжая аналогию с шахматами — «они же умеют играть» (С) и поэтому им скучно играть похожие партии. Они могут «для лулзов» взять и пожертвовать пару пешек. Или ферзя. Или могут бесконечно выстраивать фигуры на доске красивыми рядами, называя это «рефакторингом» или «реализацией паттерна». И очень редко задаются вопросом — «А кто оплачивает банкет?» (С)
А оплачивают его серьезные дяди, которые прежде всего считают деньги и время. И им дела нет до веселых программистов, им надо знать «когда?». И они постоянно задают этот вопрос физику-ПМу. И ответ «месяца через два» или даже «скоро» их не устраивает. Им нужны цифры и проценты. Поэтому ПМ и рисует планы, схемы и графики. Переводя вдохновение программистов в скупой язык цифр. И дяди дают программистам новую банку варенья и коробку печенья.
А если не будет никакого плана — то будет не работа и результат, а анархия, все весело проведут время, завалят проект и дружно пойдут искать новую работу.
Это есть такое. Программистов достаточно опытных мало.
Личный опыт подсказывает, что если люди воображают себя творческими личностями, то они никогда не будут спускаться на Землю, да и программисты из них плохие. Программирование — раздел математики, точная наука. Никакого творчества быть не должно.
Этому надо учиться. Т.е. эволюционно проектировать, использовать ТДД. И не понятно, как научить. Курсов по этому делу нету, книжки читать не заставишь, но и книжек с тем, чтобы были примеры прямо пошаговой работы, а не простенькие рафинированные примеры рефакторинга — тоже нет или мало.
Когда эта техника войдет в подкорку, тогда творчеству места не остается.
А неопытные программисты вечно место для фана находят. Вместо кода страшный говнокод, ни ООП, ни SQL не поняты, зато любой новый только услышанный фреймворк пытаются в проект затулить. Причем невозможно добиться ответа на вопрос — какое для этого основание и какую задачу с т.з. бизнеса это решает. Просто потому что новенькое, красивенькое и КАЖЕТСЯ удобненькое. А по факту — не позволяющее рефакторить, покрыть тестами и вообще понять потом, что в коде будет происходить.
Это я из жизни прямо сегодняшнего утра. Накипело.
Личный опыт подсказывает, что если люди воображают себя творческими личностями, то они никогда не будут спускаться на Землю, да и программисты из них плохие. Программирование — раздел математики, точная наука. Никакого творчества быть не должно.
Этому надо учиться. Т.е. эволюционно проектировать, использовать ТДД. И не понятно, как научить. Курсов по этому делу нету, книжки читать не заставишь, но и книжек с тем, чтобы были примеры прямо пошаговой работы, а не простенькие рафинированные примеры рефакторинга — тоже нет или мало.
Когда эта техника войдет в подкорку, тогда творчеству места не остается.
А неопытные программисты вечно место для фана находят. Вместо кода страшный говнокод, ни ООП, ни SQL не поняты, зато любой новый только услышанный фреймворк пытаются в проект затулить. Причем невозможно добиться ответа на вопрос — какое для этого основание и какую задачу с т.з. бизнеса это решает. Просто потому что новенькое, красивенькое и КАЖЕТСЯ удобненькое. А по факту — не позволяющее рефакторить, покрыть тестами и вообще понять потом, что в коде будет происходить.
Это я из жизни прямо сегодняшнего утра. Накипело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт и знания – основа любой оценки