A>>p.s. Если серьезно процесс разработки есть в любой компании которая разрабатывает софт. Процесс бывает хороший и плохой, а так же формализованный и неформализованный. Почему-то многие считают, что хороший процесс тот который формализованный вусмерть, и про него обязательно должна быть написана книжка.
A>>У нас процесс свой. Где-то он плохой, где-то он очень хороший. Сфокусирован не совсем на тех проблемах которые в нормальной софтовой компании происходят(если вкратце основные проблемы у нас не с кодом, а с данными), и некоторые из наших проблем другой компании осознать сложно(например, пойми что нормальному программисту чтобы получить бету достаточно нажать F5 или сказать gdb ..., а у нас полная бета это кластер из 800 серверов, и нужно нетривиальные телодвижения провести чтобы ее получить, т.к. по кластеру на каждого из 250 поисковых разработчиков мы не можем себе позволить).
A>Ну да, какой то процесс есть везде это верно. Я хотел обратить внимание не столько на процесс а на подход к планированию и привел пример. Если руководитель говорит что задача проста и он бы сделал ее очень быстро, не приводя аргументов по оценке (а просто агрументируя тем что разработчик, например бездельник), то это не говорит о хорошем подходе и вероятно негативно влияет на процесс.
Это не наш случай (У нас на самом деле про примерно 1/3 задач вообще нельзя в начале ее разработки сказать, можно ли ее сделать или нет не то что сколько времени это точно займет. Мой любимый пример: есть задача сделать, чтобы красивые(с хорошим дизайном) сайты в Яндексе ранжировались выше, попробуй предсказать сроки, на старте)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев