В одной из прошлой статей двое людей (Станислав Малкин и Нечаев) высказали одну и туже мысль “Со спамом надо бороться”.
Сражу скажу, что имеется в виду спам в блогах (когда кто-то пишет комментарий “Хороший блог” и дает ссылку на завод по производству кровельной стали).

Меня вот слегка это удивило, так как я не чувствую однозначности в этом вопросе.

Собственно вот те мысли которые роятся в моей голове одновременно:

- Спам - это явная фигня и положительной вещью ее не назовешь.

- Почтовый спам вещь неприятная, но мне проще удалить десять тупых писем, чем спам фильтр урежет мне одно важное.

- Спам в блоге меня не сильно напрягает. Ну, кто-то написал мол “хороший пост” и создал себе таким образом еще одну ссылку.

- Да, я осознаю, что на ссылка кто-то зарабатывает. Но меня не волнует, что кто-то зарабатывает на грязных вещах, которые меня не трогают.

- Спам уменьшает релевантность в поисковиках. Но с другой стороны, тогда это их задача писать спам фильтры и оценивать, что спам, а что нет.

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

А что вы поэтому поводу думаете? Надо бороться, желательно бороться или ну его нафиг?

Originally published at Блог об IT бизнесе. Please leave any comments there.

Ничего общего с бизнесом, пожалуй что-то есть общее с программирование.

Меня, удивляют люди, которые мыслят по следующей схеме:

“Все успешные люди носят костюм, вывод чтобы быть успешным нужно носить костюм”. Для подтверждения еще подопрем это тем, что вон “бомжи костюмы не носят и поэтому они не успешные”.

Краткий ввод в курс булевой алгебры (может правда я ее путаю с алгеброй логики).

Если из A (”Человек успешный”) следует B (”носит костюм”), то это НЕ значит, что из B (”носит костюм” следует A (”человек успешный”).

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

Да, что там. Я и сам бывает этим грешу. Например, вся серия про Программистский синхрофазотрон построена на идеи, что одна переменная (вид оплаты) может повлиять на результаты всей системе (эффективность программистов). Но замечу, по ходу трех статей я согласился, что еще миллион переменных вовлечены и взаимосвязаны.

Хотя прошлая статья на тему логики/дебатов не пошла, все равно дал на нее ссылку.

Originally published at Блог об IT бизнесе. Please leave any comments there.

Итак прошло фактически пол года,  с тех пор как я выложил нашумевшие у меня в блоге статьи Программистский синхрофазотрон (часть 1 и часть 2).

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

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

Итак начну из далека.

Пусть есть электрик Вася, сидящий на зарплате, и пьющий водку в рабочее время. И вдруг к этому Васе приходит белочка и он  думает , а чего это я водку все пью, лучше бабла подзашибу. Но блин, даже если я начну вкалывать, то дай бог мне подымут зарплату на 20%, лучше я пойду к своему начальнику и скажу, мол давай работать сдельно. Так Вася и делает. Приходит к начальнику и говорит, так мол и так, с водкой завяжу, сдельно работать будем и тебе лучше (я в пять раз больше сделаю и качественней делать буду) и мне лишняя денюжка в кармане. Начальник чешет голову и говорит, ладно Вася - починка розетки - 5 рублей, починка короткого замыкания - 10 рублей, полная проводка квартиры - 100 рублей. Если у заказчика все после этого через неделю сгорело - то с тебя вычет в двойном объеме. Проходит год, Вася шустрит, иногда правда клиенты ругаются, но суммарно все довольны - Вася при деньгам, начальник троих других электриков уволил, так как Вася за троих справляется, клиенты - счастливы не нюхать перегар Васи.

История вторая - есть Петя строитель. Так же самая картина маслом, но пьет он не водку, а пиво. И договаривается за 1000 положенных кирпичей. Начальнику тоже по душе, чтобы Петя работал и компания на нем деньги делала. Да, и теперь кладет кирпич в три раза быстрее, и при этом теперь больше его построек соответствует ГОСТу 1274-32-12б по укладке кирпича.
История номер три - есть Коля, модный массажист, делающий все виды массажа начиная от Боливийского и заканчивая массажем под названием “Рессора Белаза”. Коля, правда пьет уже не водку и пиво, а коньяк (не меньше 3 звездочек), но это мало что меняет. И вот он приходит к начальнику и говорит, а давайте я буду работать сдельно и буду делать все массажи в 5 лучше и в 5 раз быстрее. И вот тут начальник, выпучив глаза, говорит Коле…. Коля, а с коньячком-то видно пора таки завязывать, ты что с дуба упал в 5 раз быстрее массаж делать? Да и как мы будет проверять, что ты в 5 раз качественнее массаж сделал? У тебя что же есть массажеметр? Так, что пойди ка ты Коля, отдохни немножко и с свежими мозгами назад на зарплате работать возвращайся.
Ну, теперь более серьезно. Какова разница между вариантом Васей, Петей и Колей? А разница то, что в первых двух вариантах есть достаточно простое количественное измерение (связанной с доходом) сделанной работы и определенный (разумно измеримый) качественный уровень. В третьем же варианте, хотя количественное измерение есть, но оно не связанно с доходом и качественного измерения нету.

И теперь мы наконец возвращаемся к нашим горе-программистам.

С одной стороны, программисты (включая меня) очень хотят чисто сдельную оплату. Причем не просто сдельную оплату (такую как имеют freelancer’ы), а сдельную оплату внутри фирмы, когда дополнительной работы по поиску клиентов, ведению бухгалтерии у них нет, а вот денег можно зашибить дофига, если ты достаточно эффективен.
Кстати, коротенькое замечание сдельная = fixed cost за задачу, а не почасовка. Почасовка - это фактическа зарплата, просто в зависимости от того, сколько отсидишь на работе. Концептуально почасовка не меняет отношения к тому на сколько быстро хочется решить задачу. Я бы даже сказал, почасовка наоборот двигает человека в направлении растягивания задач.
Так вот, возвращаясь к тому, что программисты хотят сдельную оплату. Есть исследования, которые показывают, что отличный программист может быть эффективнее среднего в 10 раз. Соответственно, перед глазами мелькают цифры с 5-6 нулями за год
И вроде все было бы хорошо, если бы не
- Отсутсвие типовых задач
Фактически сама по себе - это не проблема, но я покажу, во что оно выливается ниже.
Тот же электрик или строитель, да и даже массажист имеет вполне ограниченный набор типовых задач. Их может быть скажем сотня, но все таки сотня разных задач - это вполне разумное число. И эти задачи можно записать.
- Отсутсвие количественной оценки задачи
Вот это проблема, которая вытекает из первой. Так как типовых задач нет, то все задачи не типовые. Для типовых задач, даже если их нельзя оценить впрямую, то можно оценить чисто статистически, сколько они занимают и какую прибыль они приносят. В случае, если же задачи не типовые, то начинается проблемы с их оценкой. И дай бог, если задачу можно оценить каким-то разумным методом. В программировании же, оценка чаще всего очень эмпирическая и +/- 30% даже на небольших задачах считается вполне неплохой точностью.  В добавление к этим проблемам, еще зачастую единственный человек который может дать оценку - является тот самым программист, работающий на проекте. И начальник никак не может проверить, дал ли он настоящую оценку или завысил ее в три раза.

Соответственно, начальник не может вывесить прейскуранта (как было сделано для Васи и Пети).

- Отсутствие измеряемого качества

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

И поэтому в ушах начальника это звучит так “Давайте я увеличу мое субъективное вложение в 5 раз, а вы мне увеличите объективную зарплату в 5 раз”. Так в жизни не бывает, что субъективное оценивается равным объективному. И кстати, именно поэтому хорошие программисты получают зарплату в 2-3 раза больше средних, а не в 10. Так как они только субъективно в 10 раз эффективнее, и то непонятно по чьим измерениям, когда же субъективное конвертируется, то на выходе получает большая в 2-3 объективных раза зарплата.
Фух… Что-то я начал запутываться, но думаю вы меня поняли. Вся проблема именно в отсутствии объективных оценок. Поэтому думаю к такому виду сотрудничества как я писал в первых частях - IT бизнес таки не придет.

Воооот… Ну и очень хотелось бы услышать ваши мнения, комментарии и идеи.

Дополнение N1: Итак, давайте, оценку = estimate из понятия абстрактного (а-ля сферический конь в вакууме) переведем на понятие реальное. Есть конечный человек которые делает оценку задачи.

Ситуация 1. Оценку делает менеджер, которые с кодом не работает. Я не верю, что человек не работающий с проектом может дать насколько нибудь разумную оценку.

Ситуация 2. Оценку делает каждый для себя. В таком случае, люди могут завышать оценку, тем самым выбивая деньги из фирмы.

Ситуация 3. Оценку делает team lead или другой опытный разработчик имеющий большой опыт на проекте. Это достаточно разумная практика, но в ней есть две проблемы. Даже team lead не дает точную оценку и очень обидно будет программистам, которые недополучат денег из-за ошибки team lead’а. Вторая проблема, что ситуация 3 вырождается в ситуацию 2 для самого team lead’а. То есть самый опытный человек делает оценку для самого себя и может ее завышать.

Учитывая, что весь этот сыр бор с программистским синхрофазотроном обсуждается именно для самых толковых программистов, то Ситуация 2+3, крайне важна. Непонятно, кто будет оценивать оценку team lead’а.

Дополнение 2. У многих возникает удивление. Типа, если программисты станут в 3 раза быстрее работать, какого фига они сейчас так не работают. Так что, эти заразы, работают не на полную мощность.

Так вот, как руководитель и программист в одном лице скажу,  да, программисты практически всегда работают не в полную силу. Кстати и не только программисты. Фактически в любой профессии если человек не дикий трудоголик то он в конечном итоге работает по возможному минимуму. И фактически все программисты - на работе читают блоги, смотрят YouTube, переписываются по ICQ с знакомыми. И это на самом деле выходит за рамки - передохуть подумать.

Но эта ситуация устраивает работодателя, так как он знает, если программиста выгнать, то другой будет делать тоже самое. Может если на рынке будет кризис, то тогда программисты поднапрягутся, а так просто люди сидя на зарплате не видят смысла вкалывать.

Originally published at Блог об IT бизнесе. Please leave any comments there.

Есть очень-очень стандартная ошибка у всех начинающих программистов, которые стали бизнесменами.Вместо того, чтобы нанять кого-то и платить ему за делание вторичных дел они начинают делать это сами. Я сам проходил через эту стадию, когда я был вовлечен буквально во все действия в компании (начиная с стратегического планирования, заканчивая ремонтом стульев).Собственно, откуда растут тут ноги

- Я могу сделать это лучше других.

Потрясающая формула, которая способна превратить вашу жизнь в ад (просто потому, что дел станет больше чем времени).

- Я толком не могу контролировать, что они сделают это качественно.

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

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

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

- Я же трачу на это деньги.

Частично, я об этом писал в статье “Умение оценить нерабочее время“. Подумайте, вы можете делать дело (чинить стул), которые не принесет денег фирме и стратегическое планирование, которое в удачном случае может принести серьезную прибыль. Соответственно, нужно оценить стоимость своего часа и все задачи которые лежат ниже этой стоимость должен делать кто-то другой.

Дополнение от Станислава Малкина:

- Программисты не любят переходить к следующей задаче

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

Я думаю все помнят этот анекдот с длинной бородой:

Сидит программист глубоко в отладке.
Подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке, а садится на западе?
- Ты это проверял?
- Проверял.
- Хорошо проверял?
- Хорошо.
- Работает?
- Работает.
- Каждый день работает?
- Да, каждый день.
- Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!

Так вот. Я не раз бывал на месте этого программиста, когда-то что-то блин изменил и все упало и три часа возишься, чтобы оно заработало. В это время QA и менеджеры прибегают и рвут на себя волосы, крича, то, что ты зараза весь проект своими фиксами завалил.

На самом деле, эта одна из самых моих нелюбимых фраз (от программистов) что-нибудь типа “Не трогай это, оно очень ненадежное/сложное”.

Собственно говоря, как только есть такая фраза, то это значит, что в engineering есть серьезные проблемы. И вероятнее всего на проекте нету достаточно хорошего программиста.

Пожалуй сразу оговорюсь, если это legacy система, которая доживает свои последние дни, то фиг с ним, действительно трогать наверное не стоит. Однако, чаще всего такое произносят о какой-то части кода для проекта в самом расцвете сил.

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

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

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

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

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

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

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

Уверен, что люди которые со мной работали слышали эту фразу много-много-много раз.

Но, начну с начала. Начинается все с того, что есть гуру Вася или немерно крутая фирма Мугл (кстати, если скрестить Microsoft + Google то как раз выйдет Moogle). И вот по ходу своей жизни, Вася бросает фразу “Самое важное это строить архитектуру Model-View-Controller, а остальное херня” или этот самый Мугл говорить, нанимайте самых лучших специалистов и все будет у вас пучком.

Ну, и соотвественно вокруг, тысчи почитатей и обожателей, начинают шептать… “о… да… я всегда знал, архитектура MVC - это круто… это единственное важное” или “нанимать самых лучших, точно, как мы раньше не доперли, самых лучших”.

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

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

Ну, условно говоря, какая MVC для написания драйверов? Или какое нанимание лучших в случае, когда нужен средний человек для выполнения какой-то руттинной работы в малом Перепурдянске?

Собственно говоря, даже тогда, когда фраза  применима у нее есть границы. Предположим - хороший чистый код для программы всегда хорошо. Но это не значит, что чистить код надо до дыр. Это не есть цель, это метод. И нужно понимать, что стоит за этим методом, какая более высокая цель.

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

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

Две ситуации, чтобы доказать, что максимизации прибыли еще не самоцель

а) Петя продал все запчасти для холодильников которые были вместо 6 месяцев за 1 неделю. Петя вроде большой молодец. Вот только новая партия не прийдет раньше чем через 3 месяца. И это значит, что все остальные заказчики уйдут к конкурентам, плюс VIP заказчики не получат деталей тоже. Прибыль максимизированна, но на очень коротком сроке.

б) Берем более длинный срок (скажем год). За три месяца до окончания года, большая фирма увольняет 1000 человек, и экономит этим очень приличную сумму. Проходит пол года, обнаруживается, что на всех проектах не хватает людей.

Можно продолжать до бесконечности.

Собственно я хочу сказать, что когда фраза начинает возносится в нечто божественное, спущенное свыше, она тут же теряет свой смысл. Особенно мне не нравиться, когда выбирается один элемент из сложной системы и ставится краеугольным камнем (например MVC). Это лучший метод задурить головы молодежи и получить вместо движения к цели, просто следование методу.

Кстати, даже фразу “Без фанатизма” нужно воспринимать с некоторым сомнением. Вот такая вот рекурсия.

Originally published at Блог об IT бизнесе. Please leave any comments there.

Надеюсь, что все знают старинный анекдот с бородой:

Цирковой фокусник рассказывает о своем номере.
-Выхожу на арену во всем белом белый смокинг, цилиндр, перчатки. Достаю пистолет и стреляю в подвешенный над зрителями пузырь с дерьмом.
-Ну хорошо, а в чем же заключается фокус?.
-Фокус в том, что все в дерьме, а я - в белом!.

Так вот,  что я хочу сказать…. То, что зрители обычно просто “в восторге” от такого фокуса.

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

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

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

Кстати, очень-очень частая проблема для молодых (неопытных) дарований и не слишком дарований. Так как толком они еще ничего не сделали, но амбиции хлещут через борт, то они начинают говорить, что все вокруг полные дураки и не делают ПРАВИЛЬНЫХ и ХОРОШИХ решений, которые естественно само молодое дарование могло бы сделать одной левой ногой.

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

P.S. Абсолютно не относительно темы: Отрицательные стороны фриланса.

Originally published at Блог об IT бизнесе. Please leave any comments there.

Сразу предупреждение, статье очень с боку темы блога.

Небольшой ответ/заметка на пост в блоге Павла Егоркина (извиняюсь, если неправильно написал имя, не смог его на блоге найти).

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

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

Тем не менее, выражу две противоположные мысли

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

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

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

- С другой стороны, представьте себе, если бы лишние1.5 триллиона долларов были “впрыснуты” в индустрию. Как пример возьмем IT.Это сумма сравнимая со всей IT областью целиком. Я думаю, это дало мощнейшее развитие и скомпресовало бы десятилетия в годы.

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

К чем это я веду…. Что в любой самой жуткой вещи (как война) есть смысл и есть развитие. Иначе не было бы войн.

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

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

Originally published at Блог об IT бизнесе. Please leave any comments there.

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

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

а) Стеклянный потолок, который я обсуждал в своих статьях.

Мой доход, как разработчика/архитектора/менеджера слишком близок к стеклянному потолку, чтобы его не замечать.

Я бы сказал, есть только два направления, которые могут серьезно поднять потолок, при том, что я буду оставаться наемным рабочем - уходить в sales или становиться верхним менеджерским составом (а-ля CEO, CTO и т.п.). И то и другое на самом деле пол шага от полноценного ведения своего бизнеса.

б) Устаревание знаний

Как технарь, фактически весь запас моих знаний устаревает в течении 5-10 лет. Например, то, что я знал 10 лет назад - уже просто никому не нужно (Turbo Pascal, Basic, программирование под DOS). То, что я знал 5 лет назад, полуумершая система (PalmOS).

Я вполне нормально отношусь к идее учиться всю жизнь. Это то, что прийдется принять как данность, в новом подвижном мире. Но, вот не прет меня идея, что 80-90% знаний через 10 лет можно будет спустить в унитаз.

Для технарей, что остается в сухом остатке за 10 лет - это умение строить архитектуру программ, знание нескольких языков (один из них должен выжить 10 лет). Большинство знаний по операционной системе, платформам, библиотекам становятся абсолютно устаревшими.

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

А что вас движет (конечно если движет) в сторону бизнеса?

Originally published at Блог об IT бизнесе. Please leave any comments there.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Originally published at Блог об IT бизнесе. Please leave any comments there.