Одна из самых крупных проблем в IT, что гигантское количество менеджеров считают, что количество переходит в качество и что если написать кучу говнового кода, а потом посадить кучу молодых программистов, которые его будут фиксить день и ночь (на самом деле, добавляя зачастую тот самый говно-код), то в один прекрасный день продукт должен заблестеть всеми красками золота.
Так вот, вне зависимости от того, сколько времени будет потрачено по латанию плохого кода, он не станет хорошим. Скорее он может только стать от этого хуже.
Вторая вещь, это то, что, если в какой-то момент даже продукт считался более менее хорошим, многие менеджеры сразу делают из этого вывод, что код тоже хороший. Хорошесть продукта можно оценить по разным параметрам и возможно sales и довольны тем, что презентация продукта проходит гладко, но это нельзя приравнивать к тому, что код хороший и стабильный.
Единственный метод, улучшить качество кода, это посадить более профессиональных программистов на его разработку. Качество в этом смысле как раз равно ситуации, что девять женщин не могут выносить ребенка в девять раз быстрее, чем одна. Так, что решать вопросы качества можно только улучшение качества кадров, а не количеством кадров.
P.S. Кстати, это непосредственно связано со статьями:
Ремонт нельзя остановить, его можно только закончить.
Ваши слова, да менеджерам в ухи!(с)
Аналогічно, знаю проекти, які добре написані, класно спроектовані, але … не продаються.
Безусловно. Хороший код не отменяет того, что продукт нужно продавать.
Просто, мне гораздо больше попадалось коммерчески потенциально успешные проекты, которые в результате «не взлетали» именно из-за того, что разработка погрязала в отладке.
Я бы сказал, что хорошие продажи — это то, что помогает прямо сегодня. Хороший код, это то, что помогает завтра.
Надо просто понимать что конкретно требуется: либо заниматься красотой кода, или подрубить бабло. Очень часто эти вещи плохо совместимы. Так как на поддержку хорошего качества кода нужно время и конечно хорошие специалисты, и еще не известно будет ли это того стоить или нет. Хотя в длительной перспективе о преимуществах спорить не надо.
А вот чтоб подрубить побольше бабла надо пораньше конкурентов выкинуть продукт, пусть даже еще сырой на рынок и загрести лопаткой банк, так например поступает майкрософт и довольно хорошо себя чувствует 😀
Продается-то не код, а продукт!
Как мне кажется, Майкрософт так уже не поступает (кстати и особо и не поступала).
Вообще это красивая городская легенда о том, какой плохой код у Microsoft….
Да, я помню когда Windows 95 падала от каждого чиха.
С другой стороны, важно все таки не просто считать количество ошибок, а считать количество ошибок деленное на размер кода. Бьюсь об заклад, даже для Win95 коэффициент был достаточно неплох. А сейчас он вероятнее всего еще выше (причем он явно лучше чем у множества других компаний).
Насчет подрубить бабла vs хороший код. Все таки программное обеспечение — это не поставки наркотиков. Это в наркотиках, привез, срубил бабла и исчез.
Сейчас потребитель стал достаточно переборчивый. И выбрасывание сырого продукта на рынок не всегда приносит бабло. Да, есть все эти сайты Одноклассники, которые работают через пень-колоду. Но опять же, только из-за того, что пост-советский потребитель привык к всему пиратскому (то есть, черт с ним если работает плохо, все равно в support обратиться не удастся).
В общем, я к тому, что да, продается не код, а продукт. Но, когда год говно, чаще всего продукт нестабильный. А нестабильный продукт, люди не так активно покупают.
1. «Как мне кажется, Майкрософт так уже не поступает»
Поставь себе висту и обновление
2. «Все таки программное обеспечение — это не поставки наркотиков»
Продажа ПО идет по подьемам на 3 месте после наркотиков и оружия! И как раз тот же майкрософт заинтересован в подсадке, и все делает для того чтоб и иглы не слезли. Я не хочу сказать что это «ужасно», я просто называю вещи своими именами — это эффективный способ развития бизнеса.
>Поставь себе висту и обновление
Виста — это много-много миллионов строк кода.
Если, скажем у них ошибка на каждые тысячу строк, то естественно будут видные тысчи ошибок.
При этом, 1 ошибка на тысчу строк — это потрясающее качество.
> Продажа ПО идет по подьемам на 3 месте после наркотиков и оружия!
Тем не менее, стратегии продаж у большинства фирм сильно отличаются от продажи наркотиков.
Да, есть Microsoft, которая очень серьезная монополия и этим пользуется. Но Microsoft это одна компания, а есть еще сто тысяч компаний, которым приходится продавать ПО другими методами.
… гигантское количество менеджеров считают…
и
… многие менеджеры сразу делают из этого вывод…
Да?! 🙂 А количественно это сколько? Есть цифры? На основании каких исследований сделані такие выводі. Или это лишь предположение? Возможно, стоит немного поубавить пыл? 😉
FYI:. Из 8 менеджеров, работу которых я лично знаю (приблизительно за последние 5 лет) ни один не выссказывал подобных глупостей.
Может, вы называете менеджерами в IT не тех людей? Может, вы немножечко их перепутали со студентами/стажерами/практикантами (подставьте свой вариант)? Я вот знаю довольно много IT-шников не имеющих квалификации менеджера проекта/продукта (подставьте свой вариант), и выполняющих некоторые функции по управлению проектом. Но, как бы вы не удивлялись, их не считают менеджерами. Странно, да? 😉
У меня нету статистики. Свои выводы я делаю чисто на своих наблюдениях.
Тоже самое, когда я выхожу на улицу и вижу, что в небе много птиц. Я говорю «в небе много птиц».
Естественно мои выводы зачастую неприменимы для других людей. Сравнивая это с птицами… Я не могу сказать, что сейчас по всей земле, много птиц в небе.
В общем то, что вижу о том и пою.
Плюс, зачастую менеджеры может и не высказывают глупостей, но вполне их делают.
И когда возникает ситуация, то кидают молодежь на пофикс сложных проблем, чем только
добавляют проблемы.
Замечу, что я не сказал, что все менеджеры так делают. Но уж очень многих я видел, которые этим страдают. Да, вы правы, многие из этих менеджеров не имею серьезного опыта или имеют, но плохой опыт. Но тем не менее они занимают менеджерские позиции в IT компаниях.
Так и нужно делать оговорку «занимают позиции» 🙂 Просто, при прочтении поста без подобной оговорки у множества сегодняшних или позавчерашних студентов (а именно они являются большей частью аудитории таких блогов) сложится впечатление, что:
а) IT-менеджеры «в основной своей массе» (а при отсутствии конкретики — звучит как ВСЕ) склонны создавать проблемы там, где их не было бы при отсутствии этих самых IT-менеджеров;
б) Достаточно изучить основные «типичные» ошибки IT-менеджеров, и уже можно идти на собеседование на эту должность в БОЛЬШИНСТВО компаний. Просто потому, что на фоне тупых людей легче показать себя умником-отличником в менеджменте.
Подобных выводов не сделает профессионал. Но профессионал и полезных выводов не сделает. Просто удивится в стиле «хорошо, что я не попадаю в такое правило. а являюсь исключением».
Виктор, вы согласны, что подобное вполне вероятно, и такие выводы деструктивны/регрессивны по своей сути?
P.S. Предлагаю на будущее немного аккуратнее выбирать формулировки, и описывать не только личные ощущения, но и продумывать то мнение, которое может сложиться у аудитории с более низким уровнем знаний.
«…именно они являются большей частью аудитории таких блогов…»
да ну? можно статистику в студию? желательно с выборкой стран, возрастных групп, тематикой блогов и методах исследования.
По остальной части, мне непонятна склонность к поучению кого либо. Мне кажется блог — это способ выразить свой взгляд на тот или иной вопрос, обсудить какую либо тему с другими интересующимися, возможно поспорить. С какого бодуна человек(и) должны задумываться о выводах неокрепших умов, тем более, если они их делают на основании блогов??? Если делают — туда им и дорога, подростут — поумнеют. По крайней мере, в случае, когда речь идет об IT-блоге, то есть достаточно безобидной теме, не затрагивающей религию, вопросы социального плана и т.д. Блог — это не курс лекций по управлению персоналом блин…
Спокойствие, только спокойствие 🙂
Виктор обещал добавить опросники, так что можно будет собирать статистику по таким вот утверждениям. Понятно что не очень репрезентативную, но все таки интересно какие люди посещают блог и как они смотрят на разные вопросы.
Да, пора бы уже прикрутить.
У меня пара вещей весят, которые хочу доделать
а) ЧТобы в письма писало ответ на чей комментарий и опросник
Фух… С ReplyTo в email’ах поборолись.
Теперь остались побороть вопросник.
Ну и с вопросником разобрались 🙂
В многом, я согласен с Keks’ом, который отписал. Только, я не такой резкий в выражании своих мыслей.
Вот пункты зачем я веду блог:
а) Устаканить свои мысли в голове.
Как только я записываю их, то они сразу оттуда пропадают.
б) Стать знаменитым
Шучу, конечно. Но, есть в этом таки толика тщеславия, глядеть на счетчик подписчиков RSS, который планомерно идет вверх и думать, вот блин я ж умнючий.
в) Поделиться мыслями с другими.
Вполне возможно, кто-то найдет их инетересными или не дай бог, даже сможет их использовать во благо.
г) Может быть завести новые интересные знакомства в IT
А вот цели которых я НЕ ставлю (относительно этого блога):
д) Обучить глупых
е) Заработать денег на этом блоге
В этом смысле, мне действительно все равно, какие выводы сделают еще несозревшие умы. Все равно, я всем не угожу и как бы я мысль не формулировал, то кому-то она не понравиться.
е)
Хто резкий, я резкий? Та я вообще как ситро 🙂
По теме же поспорить трудно. В очередной раз выходим на формулу время, цена, качество. Я не верю в реальность оптимизации «цена, качество» за счет времени, по крайней мере мне не попадалась ни одна компания, которая на это шла в долгосрочной перспективе. Соответственно у нас остается один вариант — «качество, время» за счет увеличения стоимости, которая вероятнее всего и пойдет на оплату труда более квалифицированых программистов.
Да, я тоже заметил, что на самом деле треугольник фиктивный.
Засчет удлинения времени очень редко можно понизить цену и выдержать качество.
А кто сказал, что треугольник именно такой? 🙂
MSF говорит о другом треугольнике (объем, время, ресурсы/цена), оставляя «качество» за рамками, потому что:
а) само наличие работающего и контролируемого процесса — уже дает определенное минимальное качество;
б) максимальную долю «некачества» вносят люди, потому что ошибаются — и здесь нужно не выбирать (цену или время), а постоянно тратить их на обучение и подготовку (есть отдельная дисциплина по этому поводу);
в) достижение «качества» в ряде направлений сводится лишь к выполнению ряда элементарных работ (выполнить функцию А с исходными данными Б и получить результат В), которые либо делаем (цена + время) либо не делаем (и невозможно оценить качество).
Так что по сути гибкого выбора и нет. Только компромисс. Но это с точки зрения MSF и ISO 🙂
По моему вообще единственный выбор/компромис можно сделать между сроки и цена и то в определенных рамках.
Здесь главное не вдаваться в крайности. Говнокод — это стратегическое преимущество продуктов. Не помню кто в подкасте упоминал, но звучит красиво 🙂 : «Плохой сделанный продукт практически всегда хорошо продается». По изложеным в коментах причинам.
А делать шедевр рынок не даст, хотя разработчики, имхо, не против 🙂
>“Плохой сделанный продукт практически всегда хорошо продается”.
Это не правда. Я бы сказал по другому, продукт который нужен рынку, зачастую выпускают сырым. То есть из нужности следует плохой код, но не в обратную сторону.
Шедевр делать не обязательно, но если версию N 1 купят и не стабильную (особенно если нет конкурентов на рынке), то версию N 3 не стабильную уже не купят (опять же к этому времени конкуренты на рынке уже объявятся).
И определимся с условиями, а то обсуждение ни о чем получится. Я предполагаю пустой (или с минимумом конкурентов) перспективный рынок.
Что главное для продукта, где потенциально будет много конкурентов (рынок прибыльный и большой)? Захватить рынок, пусть даже и пустой пока. Дальше лирика. Это и есть то стратегическое преимущество.
Давайте определимся, что такое плохой код для каждого. Для меня это код практически без архитектуры, без пояснений и комментариев, который читать невозможно, а это серьезно сокращает срое разработеи зачастую, нестабильность и ошибки — вещь необязательная. Если продукт выходит нестабильным, то это уже заслуга менеджеров, а не разработчиков. В версии №3 уже можно себе позволить качественный код (т.е. время на перепроектирование), т.к. пользователи уже используют продукт, а переход на что-то другое пусть и не большой, но стресс.
Опять же, краевые случаи не рассмативаем, когда развитие плохого кода займет больше времени чем перепроектирование, здесь все просто.
Сырой продукт — это зонд, расчеты объема рынка порой врут.
PS. Каюсь, с цитатой я мог и наврать, давно было. Но смысл в контексте правильный. Кстати подкаст с itblogs про образование.
PPS. Я за хороший код, а также за разумное допущения «говнокода».
Полностью согласен с вашими комментарием при указанных допущениях.
В посте правда я рассматривал именно ситуацию развития продукта.
Увы, я не указал это явно.
Я писал «количество переходит в качество и что если написать кучу говнового кода, а потом посадить кучу молодых программистов, которые его будут фиксить день и ночь»
То есть код уже написан и пришло время его улучшать (как раз та самая версия 2 или 3). Как вы четко заметили, нужно перепроектировать или рефакторить. Причем нужно, чтобы это зачастую делали либо лучшие программисты, либо если программисты были неплохие, то дать им не слишком сжатые сроки (как было в версии 1).
>PPS. Я за хороший код, а также за разумное допущения “говнокода”.
У меня абсолютно такой же подход. Я не против плохого кода, я против неправильного подхода по улучшению плохого кода. В этом смысле много молодых программистов латающих дыры, не улучшают такой код, а ухудшают его.
Согласен не все 100
Согласен полностью за исключением того, что фиксить код все-таки тестировщики должны. Но даже хороший тестировщик не спасет от плохого программиста, когда с каждым фиксом добавляются новые баги.
Но общая мысль подходит для всех IT-шников.
М…. «фиксить код все-таки тестировщики должны»
Не совсем понял этого предложения. Все таки программисты фиксят, тестировщики — тестируют.
сорри, невнимательно прочитал, сонный был:)
😉 как говорят, no problem
Решил написать еще один комент, уже ближе к тексту поста 🙂
«…что гигантское количество менеджеров считают, что количество переходит в качество и что если написать кучу говнового кода…»
О каких менеджерах речь? Сэйлз-менеджер, аккаунт-менеджер, менеджер проекта?
Если первые два и их «родственники» — то пусть считают, разработкой управляет ПМ, это его забота обеспечивать качество продукта. И я искренне сочувствую организации, где разработкой управляет сейлз.
Если ПМ — то в печь такого ПМа.
Вывод «хорошо продаваемый продукт — хороший код» может сделать только сэйлз, ему простительно, если менеджер проекта тоже так думает, то его надо в печь.
Кстати, в посте затронута довольно острая проблема ИТ — кто управляет разработкой проекта (речь не о номинальной должности/роли, а о компетентности людей на каждой конкретной должности/роли).
PS. клише «многие [менеджеры/разработчики/пользователи/марсиане]» без обоснования очень скользкий прием, имхо конечно.
Первая часть поста, насчет улучшения качества кода путем посадки многих молодых программистов — относилась к ПМ (project и product manager’ы).
>Если ПМ — то в печь такого ПМа.
А я же о чем. Именно в печь. Может мне не повезло, но уж очень много я таких ПМ’ов видел.
Вторая часть поста была и о ПМ и о sales. Зачастую, если они не погружены в код, то они могут делать глупые выводы (опять же видел своими глазами), когда полуприкрученную фичу называли полностью работающей, а потом удивлялись, когда в момент продажи оказывалась, что она еле живет.
>Кстати, в посте затронута довольно острая проблема ИТ — кто управляет разработкой >проекта (речь не о номинальной должности/роли, а о компетентности людей на каждой >конкретной должности/роли).
Ох. Тема действительно больная.
Я касался ее тут:
http://victorronin.com/2008/01/09/o-razdelenii-obyazannostej-mezhdu-texnaryami-i-prodavcami/
>PS. клише “многие [менеджеры/разработчики/пользователи/марсиане]” без обоснования >очень скользкий прием, имхо конечно.
;))) Сам его не люблю. Но, как-то оно на автомате проскочило.
Все таки, где-то в мозгу есть видно функция обобщать личный опыт и навешивать его на весь окружающий мир.
«…Зачастую, если они не погружены в код, то они могут делать глупые выводы…»
Имхо, не обязательно ПМу заглядывать в код, главное создать хорошую команду, тогда и взаимное доверие будет и не будут скрывать реальное состояние дел.
Вот почему то не любят наши люди, разработчики в частности, миниотчеты писать, занимает 2 минуты в день, а весь менеджмент в курсе что да как. Приходится порой клещами вытягивать 🙂
Скрум с этим и статусом задач успешно бореться, там у задачи бинарное состояние — либо сделано, либо нет, третьего не дано.
Безусловно. Когда все работает хорошо
а) Умный ПМ
б) Ответственные и профессиональные программисты.
в) Пункт б) относится не к одному программисту, а именно к команде.
То описанных проблем не возникает.
Честно говоря Скрум не пробовал, но побороться с идиотизмом (если он присутствует) не одна методика не сможет.
Кстати, спасибо за комментирование. 🙂
Пожалуйста 🙂
тоже больная тема.
[…] Browse other articles in Инфраструктура, Менеджмент, О большом и малом, Старт бизнеса categories. « Куча г. не станет золотом. […]
«Ремонт нельзя закончить, его можно только остановить.»