90% разработки

Есть такое интересное разбивание проекта на этапы, как я называю «по правилу 90%». Я не знаю откуда я его взял, может где-то прочитал, может сам это вывел, может еще что-то, но тем не менее:

  1. Команда рано или поздно приходит к моменту когда проект «уже сделан на 90%» — что-то уже запускается (в идеалистичном use case) , есть какая-то система, казалось бы осталось лишь допилить чуть чуть.
  2. Но на самом деле это лишь начало. Дальше еще столько же до того момента когда продуктом можно будет реально пользоваться, когда он станет работать у другого человека, перестанет падать в ситуации отличающейся от идеальной и т.д. Вот тут да, снова дошли до стадии «готово на 90%».
  3. И это оказывается не все... 🙁 Теперь нужно допилить чтобы все было «красиво», удобно, чтобы это поддерживалось, запускалось из коробки, были написаны инструкции. И после уже снова «готов на 90%», тут уже и правда почти готово.


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

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

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

  • http:// xeye

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

    я в этой роли побывал )

  • http:// splix

    @xeye а, во!, или вот так 🙂

  • http:// avorobyov

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

  • http:// splix

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

    Не всегда работает, но вариант.

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

  • http:// splix

    И вот, упомянутому опенсурсу, ему то как поступать? 🙂

  • http:// avorobyov

    Опенсорс вырос из детских штанишек. Теперь и там полно неинтересной работы — это факт. Мало кто хочет быть парнем который закрутил пару гаек на авианосце.

    Сегодня разработчику проще разработать Yet Another iPhone (Adnroid) MegaSuperCalculator у уловлетворить свой интерес амбиции.

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

    Чистых проектов сообщества все меньше и меньше на фоне OpenCore компаний.

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

  • http:// AngelRain

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

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