Я уже писал статью о крупных лажах, которые я сделал.

Я вот тут покопался в мозгах, прошелся по всем заваленным проектам, которые я знал и разбил их на две категории: Бизнес и технарьская. Правда, и в ту и в другую входят разнообразные менеджерские решения. Просто одни касаются именно проекта с технической стороны, а другие с бизнес стороны.

Технарьские проблемы:

- Очень неправильный изначальный estimate (чаще всего неправильная оценка сложности нескольких крупных задач)

Чаще всего такое происходит в том случае, если кто-то не слишком умелый оценивает проект. Решается чаще всего, тем что это делает не один человек, а два человека, причем хотя бы один из них должен быть хорошо знаком с областью проекта, а второй с большим опытом работы (и estimat’ов).

- Отсутствие технического лидера (или другого опытного человека) на проекте.

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

Решение, просто - добавить технического лидера на проект.

- Развития конечного продукта на базе прототипа.

Стандартная проблема. Есть прототип, нужно выпускать первую версию, так как времени мало, то версия строится на базе прототипа. В результате на прототип (с отсутствием архитектуры) наворачивается много функциональности и архитектура не выдерживает такого количества фигни.

Правильное решение, либо привести прототип к нормальной архитектуры, либо не пытаться сэкономить время на стартование с прототипа.

Бизнес проблемы:

- Установка нереалистично коротких сроков.

Тут все просто. Технари говорят, нам нужно 12 месяцев. Бизнес отделение отвечает - есть только шесть.

Зачастую пробелема не решаема. Если вы находитесь на таком проекте - бегите с него к чертовой бабушке. Через 6 месяцев таки обнаружится что время нужно еще и бизнес отделение начнет пинать технарей и искать куда бы слинять, так как денег от продаж ждать надо будет долго.

- Установка завышенных требований к первой версии

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

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

Даже при портировании нужно разбивать на несколько версий.

- Слишком большое количество разнообразной требуемой функциональности.

Это скорее происходит на версии три-четыре и т.п. Когда программа обвешивается по самое нихочу разнообразной функциональностью, которая зачастую конфликтует с другой функциональности.

Решение это проблемы состоит в том, что раз в пару лет, возможности программы должны пересматриваться и старая и не нужная функциональность должна выкидываться.

- Малое внимание к проекту

Как написал в  комментариях eko, зачастую либо заказчик, либо product manager забывает, что если вложить денег и назначить программистов, это еще не значит, что проект будет успешный.

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

Вчера, играл с друзьями в пинг-понг (как именуют его тут, в стране заходящего солнца). И вот слово за слово, завязался разговор о текущих багах и потихоньку все погрузилось в глючность реализации JNI (java native interfaces) для какого-то Linux и ошибки в C++ коде, которые вызывается через C прослойку через JNI и т.п.

Где-то после минут десяти у меня начал активно проявляться комплекс неполноценности. Хотя это абсолютно не моя техническая область, но тем не менее, она была и не слишком ихняя. При этом люди меня повергли в ужас, количество разнообразной технической информации о java, c++, по ходу был зацеплен unicode (и его виды utf-8 и utf-16), а так реализация виртуальных машин, их оптимизация, задеты темы языков ruby on rails и чего-то еще.

В общем, после игры в теннис, я чеща голову ушел думать… Что ж блин я такое пропустил в своем интеллектуальном развитии?  Почему же, я какой-то прям таки недоразвитый?

Одна правда мысль в голову таки пришла. Достаточно много времени я потратил на развитие своих бизнес знаний и умений. И хотя они не так хорошо формализованы, тем не менее они присутствуют где-то в голове.

Но тем не менее, это не до конца ответило на возникшие вопросы.  Так что я ненашутку задумался. И вот к какому выводу я пришел. Возможно это конечно особенность программирования под мобильные платформы. Но вот примерно тот процентаж (не точный, а просто ощущение), которое играют знания в решении задачи

- знание платформы - 30%

- умение создавать нормальную архитектуру - 20%

- умение решать проблемы 20%

- понимание логики программы - 20%

- знания языка программирования - 10%

Так уж получилось, что по крайней мне, для мобильных платформ, знание языка очень-очень низкий приоритет по сравнению с остальными знаниями.

Я как-то фактически не побывал снаружи от мобильных разработок. Как оно вообще во вне?  Такие же приоритеты или что-то по другому?

Ура господа, случилось то о чем так долго говорили большевики.

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

Если кому нужно будет для блога, с удовольствием отдам фикс в хорошие руки

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

Знаете, меня убивают вот такие фразы: “Это моя любимая чашка, поэтому я ее никогда не использую ее и храню за стеклом. Поэтому она никогда не поцарапается и не разобьется”.

Как вы считаете, какова реальная ценность такой чашки? Ну, ok, будет она храниться за стеклом и ее никто не разобьет, но ведь получается, что так никогда в жизни и не попьешь из любимой чашки.

Наверно, вы уже приподымаете бровь, думая, совсем бедняга Виктор сдал. В блоге о IT пишет про любимые чашки Ан нет…

Это я пишу к тому, что меня убивает, когда люди оставляют куски ОЧЕНЬ важного и возможно полезного кода, которые мы используем в каком-то неопределенном будущем. Люди… очнитесь, либо код важен и полезен, потому, что он пользуется прямо сегодня, либо этот код представляет из себя ту самую чашку, на нее всегда молятся и никогда не пользуют.

Особенно это актуально, учитывая, то что есть системы контроля версий и можно достать всегда удаленный код из закрамов.

Да, возможно, есть ситуации, когда код нужен на завтра и его можно оставить (написал, конктретно когда и зачем он должен быть использован). В остальных случая код должен либо иди в пользование, либо в мусорку.

P.S. Кстати, я имел в виду старый код, который вроде уже и не нужен, но так как он когда-то делал что-то очень полезное, его не удаляют, в надежде, что он пригодиться.

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