90% разработки
20 мая 2010
Есть такое интересное разбивание проекта на этапы, как я называю «по правилу 90%». Я не знаю откуда я его взял, может где-то прочитал, может сам это вывел, может еще что-то, но тем не менее:
- Команда рано или поздно приходит к моменту когда проект «уже сделан на 90%» — что-то уже запускается (в идеалистичном use case) , есть какая-то система, казалось бы осталось лишь допилить чуть чуть.
- Но на самом деле это лишь начало. Дальше еще столько же до того момента когда продуктом можно будет реально пользоваться, когда он станет работать у другого человека, перестанет падать в ситуации отличающейся от идеальной и т.д. Вот тут да, снова дошли до стадии «готово на 90%».
- И это оказывается не все...
Теперь нужно допилить чтобы все было «красиво», удобно, чтобы это поддерживалось, запускалось из коробки, были написаны инструкции. И после уже снова «готов на 90%», тут уже и правда почти готово.
Ну в общем это все понятно, интересно другое: если в первом этапе у нас рулят матерые программисты, самоорганизующаяся команда, правильная архитектура и всякие хитрые технологии, то во втором уже больше качество собранных требований (заранее собранных), ну а в третьем вообще лишь процессы. Причем в третьем, в противоположность первому, иногда важнее даже начинающие программисты, потому что они согласны заниматься «не интересными задачами», точнее они еще не выросли из них. А те матерые разработчики которые начинали уже выросли, им это не интересно, и даже уволятся если им дать такую задачу. Если рисовать графики важности то получится примерно такая иллюстрация:
Отличный пример всему этому имхо весь опенсурс, часто застрявший на первом этапе. Вот, например, популярный линуксовый десктоп: в нем огромное количество крутых штук, которых нет в коммерческих конкурентах. Это все благодаря матерым программистам. Но в тоже время в нем не сделаны банальнейшие вещи, естественные у конкурентов, и естественные для пользователя. Пример: уже 6 лет висит задачка «показывать превью картинок в диалоге выбора файлов». Казалось бы самая естественная вещь, но висеть будет еще столько же времени, потому что матерому программисту заниматься такимим вещами не fun, это ниже его уровня, а вот процессов, менеджеров и стажеров там очень мало. И о сборе требований, анализе пользователя тоже никто пока не думает. Я не говорю что опенсурс весь такой, есть масса совсем противоположных примеров, но тут изначально условия существования проекта такие, поэтому много примеров.
Ну и возникает естественный вопрос: а как бы так собрать команду, и организовать процесс чтобы оптимально учесть все этапы? Выполнять проект разными командами чаще всего не реалистично, хотя иногда стоит подумать.
мая 20, 2010 в 20:36
для грязной работы есть дорогие, профессиональные консультанты, которым некуда деваться.
я в этой роли побывал )
мая 20, 2010 в 20:38
@xeye а, во!, или вот так
мая 20, 2010 в 21:24
Крутых разработчиков к с середины проекта нужно плавно выводить в новые проекты. При этом растут те кто остался, крутые опять самоорганизуются и довольные фигачат. В такой схеме есть изъян и возможно даже не один. Нужно постоянно иметь много новых проектов и людей может и не сильно крутых, но способных завершить проект.
мая 20, 2010 в 21:35
@avorobyov ну вот я примерно к этому и склоняюсь, пока. «много проектов внахлест» это конечно редкость, но можно начальную архитектуру отдавать на аутсорс, осуществлять приемку своим матерым разработчиком, и передавать своей команде «допиливающих» программистов, под его управлением. Многие примерно так и поступают.
Не всегда работает, но вариант.
А вот что делать если продукт сейчас один, и очень не хотелось бы аутсорсить его (например потому что еще нет четкого понимания результата). И в случае своей команды непонятно как потом переключить процесс, если не планируется начинать другой продукт, не запустив текущий.
мая 20, 2010 в 21:53
И вот, упомянутому опенсурсу, ему то как поступать?
мая 21, 2010 в 14:42
Опенсорс вырос из детских штанишек. Теперь и там полно неинтересной работы — это факт. Мало кто хочет быть парнем который закрутил пару гаек на авианосце.
Сегодня разработчику проще разработать Yet Another iPhone (Adnroid) MegaSuperCalculator у уловлетворить свой интерес амбиции.
В опсорс приходит жесткий энтерпрайз. Эти ребята крутят гайки как положено, правда гайки выбирают сами, причем преимущественно те, которые подороже.
Чистых проектов сообщества все меньше и меньше на фоне OpenCore компаний.
По поводу занятости «матерых», я думаю гугл и для этого в том числе позволяет работать на открытых проектах. Так сказать, выпустил пар — забожил и опять крути корпоративную гайку.
мая 6, 2011 в 19:08
Игорь, тут как раз переплетаются стили программистов которые ты где то тут описывал (стахановец, бюрократ, политик и тд) часто для матерых программистов — индивидуальные черты характера реализовать сложно креативное это да интересно, а вот выпилить мелкий баг — ну невозможно просто себя заставить
для примера: одни люди могут делать монотонную работу, но впадают в ступор от решения «необычной задачи», другие — монотонная работа вызывает зуд и тряску в руках, зато сырое решение «необычной задачи» может выдать еще в момент ее постановки
)