"1. Программист, в моем понимании не отвечает за разработку алгоритмов.
Разработчик в первую очередь занимается разработкой алгоритмов. Это две разные работы.
И в идеале они не должны совмещаться в одном лице никогда (МЛМ)."
Иван, ну тут очевиден вопрос терминологий и соответственно образов, что скрываются за терминами. Что значит "разработка алгоритмов"? Постановка задач?
Или разработка алгоритмов для достижения определенной функциональности? Ну, если у меня разработчики не будут этим заниматься - мы будем долго заниматься "разработкой" чего бы-то там ни было.
2.1. Да, я закупаю ресурсы по заниженным ценам, ибо моя цель не накормить народ.
Вы еще и закупаете ресурсы со сниженным опытом, умениями, а соответственно теряете в качестве. Каждый ваш «спец», выполняя задачу, создает маааааленький продуктик, интегрировав которые вы получаете продукт. Так вот вам ясно и хорошо объяснили, что «Люди, не имеющие представления о том, что они делают совершают просто смешные (или чудовищные) ошибки. И более того, считают, что они все делают правильно и если им не указать, они так и продолжат. Указав им на ошибку, они говорят "хмм..." и тут же ее исправляют не менее дурацким способом - они просто не понимают, что они делают, они просто пишут код, наступая на _каждые_ встречающиеся грабли. На что становится похож проект это отдельный разговор. В таком коллективе трудно работать, особенно тем, кто понимает, что в проекте и как, и уже заранее представляет чем "светит" такое "писание" и та или иная ошибка. Может те, которые за $800, потому и не идут?»
2.2. У меня есть следующий ресурс: печатная машинка, которая печатает деньги, скажем по 100 тыс. рублей в месяц. И не более. И у меня есть 100 задач, которые необходимо параллельно решать. Даже если взять крутого спеца, ему будет тяжело в течение дня переключаться с одной задачи на другую (разве нет)? А за те деньги, которые у меня есть, я подбираю максимально качественный программистов, насколько позволяет з/п - 1 тыс. рублей.
Вопрос комплектации и, собственно, проектирования (проектирование – я имею ввиду построение видения каким образом будет выполняться проект). Однозначно можно сказать, что те, кто выполняют эти 100 задач, исходя из ваших же данных, некомпетентны в ряде вопросов. Вы сами сказали о том, что берете людей без определенных скилзов и опыта. Вам, кстати, очень хорошо ответил KBV.
2.3. Я ограничен в ресурсе "деньги". При вашем подходе падает эффективность работы спеца. Да сроки увеличиваются в любом случае: или спец будет переключаться с задачи на задачу (потеря времени) или молодой специалист будет терять время. Приблизительно одинаково.
Млин, в моем подходе, мне нужно заполнить должностное место, человеком с соответствующими скилзами. Если вы хотите сказать, что у вас в продукте все задачи для неопытных и результатом вы получаете продукт высокого качества, - то будьте добры – дайте объективные показатели. Мне интересен 1 показатель – плотность дефектов на кол-во кода.
2.4. И потом у меня есть 100 клиентов по всей стране. Каждый мой спец выезжает к клиенту одновременно со всеми и через 7 дней мы все возвращаемся и продолжаем дальше работать. А по вашему мы вернемся через 14 дней. А ваш спец как эту проблему будет решать? Т.е. вообще не выгодно. И вообще если вашего спеца (дорогого) отправлять в командировку, все равно что микроскопом забивать гвозди.
Вопрос, как создавать команду. Зачем разработчика гнать к клиенту, да, причем каждого из них – вопрос отдельный, я бы не хотел его рассматривать в данном контексте. А теперь, внимание. Повторяю, уже в какой раз – мне интересны показатели. Качества. Вы хотите убедить нас, что при вашем подходе вы не теряете в качестве. Я с вами не согласен. А все остальные доводы, как вы проектировали команду – это отдельны разговор. Хотите – обсудим. Но мне это не интересно. Мой тезис – вы теряете в качестве. Потому что при выполнении задачи вы используете ресурсы, которые НЕ ПОДХОДЯТ по скилзам для этого. Объяснить, почему не подходят? На примерах?
Потому что люди НЕ УМЕЮТ работать, например, с памятью – это memory licks. Не обладают знаниями по концепциям ОО проектирования (LSP, OCP, SAP, SDP, etc.), на которых основаны, например, паттерны ООП. В результате происходит перерасход бюджета из-за rework efforts, и потеря качества. Бить себя в грудь кулаком и говорить о том, что без опыта работы перцы работают качественно – ну глупо, очень глупо.
2.5. Наш проект намного сложнее. Мы не делаем коробочного ПО. Мы работаем с конечными клиентами. Об эффективности моего управления может говорить только, то что есть реальные результаты. 2 предыдущие команды с крутыми программистами и МП провалили проекты и убили в общей сложности около 8 лет = результат 0, громадные убытки. Мы же получили результат и бабки через два - это и есть оценка. Я кстати сваливаю отсюда, можете занять мой пост и порулить, и понять что такое успех в рамках совковой гос. структуры. Все предыдущие МП действовали именно так как вы говорите, их было меньше в два раза, и получали они в три раза больше, но в итоге все команды спеклись. Т.е. усы и хвост - вот мои цифры, мой результат - итог моих расчетов. Перед тем как начать проект, естественно я тщательно изучил
работу предыдущих МП. Сделал выводы и получил результат.
Вот это интересный момент, 8 лет в пустую? Громадные убытки? «. Все предыдущие МП действовали именно так как вы говорите, их было меньше в два раза, и получали они в три раза больше, но в итоге все команды спеклись.» Так, кто им давал так действовать, если это гос. предприятие
какие-то странные у вас противоречия.
И мне особенно нравится фраза 8 лет, а результат ноль. Напоминает, байку про 8 бубликов и 1 баранку.
Что странно и шокирует:
1) 8 лет назад, не было ни одно МП, который был крутой. Не нужно говорить о том, чего не было.
2) Тщательно изучили работы предыдущих МП? Так и в чем проблема? Вы скажите бизнес домен и объем ПО (в SLOC) – и уже будет примерно ясно сколько, например, профессионалы в моей команде будут заниматься реализацией.
3. Опытные и умные за 800 баксов сюда не пойдут, потому что они опытные и умные! За 1200 может быть. И если что-то им не понравится, они свалят. А это тоже очень большой риск. Каков бы не был спец ему будет тяжело разбираться в чужих кодах. Т.е. спец нужного уровня стоит в 3-4 раза дороже! А не в два. Разве нет? Умные и с маленьким опытом, просто не дооценивают свой потенциал, который я раскрываю и использую.
Котлеты отдельно, мух отдельно. «Спец», который понюхал пороху в разработке, получил строчку в резюме – точно такой же нестабильный элемент и не от зарплаты это зависит, абсолютно – по-вашему выходит, что реальный профи, чем дороже он стоит, тем он как элемент системы нестабильние?ну вы даете. Это зависит совершенно от других факторов.
Не надо только думать, что их тут насилуют. Квартальные премии они в принципе хорошие получают. Просто хочется конечно еще больше получать. Вот и все.
По поводу квартальных хороших премий. Берем вашу калькуляцию и смотрим, что 200 килобаков – из них 8 – это премии. Считаем:
8000 / 40 / 4 = 50 у.е. в квартал. Это ХОРОШАЯ ПРЕМИЯ?
Статья конечно прикольная. Но мое личное мнение, что технологию ведения проектов необходимо совершенствовать. Все, что было придумано в прошлом веке, конечно круто, но в большинстве случаев не учитывает нынешних реалий жизни.
Абсолютно точно, - совершенствовать нужно. И где можно помочь автоматизацией, можно помогать (но это, кстати, не обязательно – об этом отдельно).
A. Масса фирмочек по производству ПО
Б. Более доступные средства разработки приложений. Теперь каждый чайник может быть программистом.
Вот это вы здорово сказали. Теперь я практически уверен, о качестве вашего ПО. Если вы считаете, что каждый чайник может быть разработчиком – у что ж, вам карты в руки :). Инженерная работа – работа мозга, и «каждый чайник может быть программистом» – ну это вы круто взяли. Видали мы такие команды и такие подходы :). И софт получается чайниковый – гремит, свистит, но не едет.
Вот, например (на данный момент задачи другие – это действительно просто пример), у меня идет разработка мультикластерной системы, с опупенной нагрузкой на каждый из кластеров + серьезная бизнес логика – мой архитектор, человек который каждый день занимается, по сути, научной разработкой, решая нетривиальные задачи. У разработчиков задачи легче, но, тем не менее – разработка компонентов системы – это разработка внутреннего дизайна и реализации. Система меняется каждый день – тут рулит рефакторинг и изначальные предпосылки и требования к разработке. И весь этот процесс контролируемый и измеряемый. Где нужны профессионалы. Куда тут присобачить чайника?
В. Низкая потребность пользователя в коробочном ПО, в заказчик теперь хочет что-то оригинальное.
и так далее...
Вот-вот, и причем он хочет на завтра часть вещей поменять. И это известно заранее, задача нетривиальная – куда тут чайник воткнуть?
Отсюда возникают следующие проблемы:
1. Тяжело выживать в этом мире фирмам действительно выпускающим качественное ПО. Потому что найдутся, те которые занимаются демпингом цен (исходя из п.А и п.Б).
По определению – качество, это, по сути, мера удовлетворенности клиента. А клиента нужно сопровождать, в срок и не допсукать факапов. Вот, например, одна из моделей измерения качества
Functionality
Usability
Reliability
Performance
Supportability
+ (and others)
FURPS+ - взято из RUP. У мотороллы, интела, да и у массы других компаний, есть свои подобные модели. Неуверен, что им тяжело выжить.
2. Пользователь хочет видеть результат уже завтра, а не через Х дней. Необходима высокая скорость создания ПО. А исходя из п.А, всегда найдется, тот кто сделает быстрее тебя.
3. Исходя из п.А, всегда найдется фирмочка, которая купит твои лучшие кадры. Или во всяком случае есть такая опасность.
И т.д.
Давайте для приличия заменим термины в статье. Бабы на машины, мужиков на механиков. А действие между первыми, на ремонт авто.
Да нет, как раз менять не стоит, потому как ремонт машины – задача в статье – задачи разные не только по классу и типу, но и по реализации, методам, средствам и самое главное ПО МЫШЛЕНИЮ. Или, хорошо, представьте себе машину, где каждая деталь может быть изменена по вашему усмотрению, где вы работаете в основном не с помощью инструментов типа плоскогубцы, а в основном лишь головой. А механические воздействия на машину (в ИТ – нажатие кнопарей на клаве) – это всего лишь малая доля вашей работы. Ну тогда, механик как раз будет работать с этой чудо машиной уже не с помощью молотка и такой-то матери – придётся башкой думать.
Изучив статью, видно, что автор не видит главной проблемы, не видит цель (т.е. придерживается подхода предыдущего века). Цель состоит не в том, чтобы механик, отремонтировал любую машину с минимальными издержками. А в том, чтобы машина всегда работала. Цель механика не провести ремонт! А привести машину в рабочее состояние.
www.xored.com – это компания автора. Он один создал продукт, который вы найдете на сайте. Сейчас у него отдельная небольшая команда, используются agile методы в разработке. Скорость – соответсвующая :). По его продукту была издана книга. Автор – владелец домена silicontaiga.com – почитайте еще статьи – может образ изменитсяПовторюсь – аналогия с механиком – не подходит. А по поводу прошлого века – то, о чем вы говорите – фабрика Генри Форда – отличный подход. Вот он как раз из прошлого века. Но не работает в ИТ в полной мере, так же как и в других наукоемких индустриях. Что-то можно поставить на конвейер. Но сам процесс мышления – нельзя. А этот процесс основной.
Как это можно сделать по другому? Автоматизировать ремонт! Максимально исключить человеческих фактор (механика) из ремонта - отсюда максимум производительности, мин. издержек. Неограниченное число клиентов. Нужен станок, который будет ремонтировать любую машину. Конечно, регулярно необходимо добавлять новые инструменты. Но с каждым днем необходимость в этом все реже и реже.
Вот и это и есть мой секрет. Именно поэтому мне не страшен не п.А, п.Б, п.В.
Конвейерное производство в ИТ?Исключить человеческий фактор? Всё ясно.
Жду тогда, показателей, раз у вас много что автоматизированокстати, вот вам задачка по автоматизации – придумайте как автоматизировать создание дизайна компоненты и ее реализацию максимально автоматизированоВы придёте к проблеме кодогенерации и т.д. Ваши идеи (точнее идеи Генри Форда) работали в начале прошлого века. ИТ – это не конвейерное производство, человеческий фактор – определяющийИначе, давно бы была бы софтина, что по нажатию кнопки генерила бы любой софт, который тебе нужноДа, работы в плане такой автоматизации ведутся – это огромные наукоемкие проекты. Видимо, Иван, вы всех их обскакали. :)Но это тема для отдельного разговора.
Да кстати. Как учитывается у вас риск потери суперпрофи? Чем у вас профи круче, тем больше вероятность его потери (или надо платить супер бабки). А значит, все время вы находитесь в состоянии нахождения на пороховой бочке. Что регулярно мы наблюдаем при развале крутых фирм. Или риск велик или теряете большие деньги. Это заранее не решаемая задача. Ее никогда нельзя допускать.
Я уже описал, что связывать зарплату и риск ухода – бред – где тут логическая связь?Основные факторы потери ресурсов (ухода кадров) – это не их зарплата. А так, выходит, что, сейчас устроившись на работу с зарплатой выше, чем у вас была раньше – вы стали более рискованным элементом в компании. Что за чушь?
(40 человек вовлечено в IT, всего в организации более 100 чел, и все цифры пропорционально увеличиваются в 2.5 раза).
Все цифры приводятся под 40 чел.
Аренда помещения $50 в год.
Закупка техники $50 в год.
Закупка лиц. программного обеспечения = более $150 тыс.
Содержание автопарка (покупка, ремонт, бензин) несколько иномарок = 70$ тыс.
Содержание бухгалтерии, руководства более $100-$150 тыс.
Выезд в командировки к клиентам $150 тыс.
Итого более $970 тыс
Иван, на самом деле тогда в стоимость «проекта» нужно включить следующее:
1. Стоимость всего транспорта и всех магистралей России.
2. Стоимость содержания правительства и Госдумы
3. Пенсии
4. и т.д.
Теперь внимание. Вы МП проекта по разработке ПО. Этот проект, можно сказать так, что часть мультипроекта. Говорите за бюджет своего проекта, а не всего мультипроекта. Вы там не МП, и бюджет у вас не 1 лям. Зачем говорить о бюджете, которым вы не управляете даже косвенно? С ресурсами техника, софт – еще можно как-то поговорить. Но и то, какая из этих частей относится непосредственно к производству ПО?
А вопрос остался открытым:
Нужны показатели качества.
Как говорил я и KBV – выполняя задачу, сотрудник должен обладать определенными навыками и опытом. Есть модели реализации команды, где использовать можно Low qulified «специалистов», но они сложны и требуют больших вложений (не обязательно финансовых, например мозговых
) по реализации. В частности, для того, чтобы покрыть недостаток скилзов, нужно обеспечить очень «быстрое» и эффективное коммуникационно-информационное пространство. Это отдельная тема, по поводу создания высокоэффективных самоорганизующихся команд.
А пока попроще вопросы. Жду от вас:
1) SLOC
1) Плотность дефектов на объем кода
2) Плотность по времени Post delivery defects на один релиз.
3) Кол-во известных не закрытых проблем на текущий момент
4) Хотелось бы особо провести метрики по коду – было бы здорово посмотреть некоторые параметры. Если вы готовы – я предложу список.
Подозреваю, что таких данных у вас нет. Тем самым считаю, что глупо оценивать качество ПО. Подозреваю, что и нет оценок для каждого сотрудника индивидуально. Нет данных для сравнения. Вот в чем дело. А продажи только начались… Да, кстати, продажи – это одно, а то как клиент будет потом работать – это другое. И зачастую, к сожалению, продажи и качество ПО – вещи далеко не связанные. Связанные они становятся тогда, когда подает объем продаж из-за того, что продукт зарекомендовал себя плохим качеством в данном целевом сегменте рынка, а маркетинг и производство во время не отработали данные сигналы.
Честно говоря, не думал, что это разовьется в такую дискуссию. Вы увиливаете от прямого ответа, СТРАДАЕТ ЛИ КАЧЕСТВО ПРИ ИСПОЛЬЗОВАНИИ НИЗКОКВАЛИФИЦИРОВАННЫХ СОТРУДНИКОВ ИЛИ НЕТ. Все остальные темы, что затронуты около – они мне, конечно, интересны, но не более того. Повторю мои тезисы:
Как правило:
1. При использовании НИЗКОКВАЛИФИЦИРОВАННЫХ сотрудников – теряется качество продукта. (можно построить систему, где можно использовать таких сотрудников, но это отдельная тема - хотите, подымем и поизучаем принципы снижения издержек, за счет более дешевых человеческих ресурсов, с более низкой квалификацией – но отдельно)
2. Растут сроки, - тем самым снижается возможность заработать. Время = деньги. Можно кучу объяснений привести, надеюсь не нужно.
Если с пунктом 2 вы согласны, что сроками приходится жертвовать – давайте разберемся с пунктом 1.
