2 Макс, Удалил бы ты это с сайта, раз признал позорищем:) И неплохо бы повторно поднять вопрос о комментариях только от зарегистрированных пользователей... А то вот HITechBlog между делом раскручивает свою копи-пастилку... Ресурс (данная часть) понемногу превращается из набора статей о разработке (и разработчиках) ПО в непонятно что...

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

2 akhavr: Не стоит опускаться до уровня предвыборных лозунгов:) Можно, оставаясь в юридическом поле, отстаивать и свою точку зрения, и свой бизнес. И если «объективно» Open Source-провайдеры не пользуются спросом на рынке, значит именно над вопросами сбыта и маркетинга нужно работать, а не над поиском «исторических причин» данной ситуации. [off] Если сможете словить за руку сотрудника «Майкрософт Украина» с конвертом, будете использовать неплохой маркетинговый инструмент: -). А пока его нет — используйте другие [/off].2 all: Что же по сути статьи, я вижу единственный вывод, который можно описать в виде анекдота: — Насколько плохо в Украине с IT? — Мы не можем оценить что-либо, поскольку даже с оценками IT у нас все плохо.- Раз нет оценок, из чего делается вывод о том, что «все плохо»? — Ну вы же сами спросили, «насколько плохо»?! Какой еще можно сделать вывод? ...- Давайте спросим по-другому (шутливо). Насколько хорошо в Украине с IT? — Мы не можем оценить что-либо, поскольку никто у нас в IT не стремится рассказывать о том, насколько все у него хорошо! — Что же здесь хорошего, если никто ничего не знает? — Ну вы же сами спросили, «насколько хорошо»?!...:) Это все, конечно же, шуточки... Но можно и более серьезный вопрос поставить каждому отдельному читателю.- Вы, как программист в Украине, какой из двух вариантов предпочтете: а) знать, что Украина в сфере разработки ПО отстает от страны «А» на «Б» пунктов в мировом рейтинге «В» 200х года, илиб) не знать ни о каких мировых рейтингах, и фактически зарабатывать достаточно для комфортной жизни в Украине, при этом знать о том, что (опять же) ФАКТИЧЕСКИ разработанный вами продукт должным образом оценен на мировом рынке IT (принес доход и активно используется годами).IMHO, чисто по-человечески вариант б) дает более точное позиционирование украинского программиста на мировом рынке труда. А то, что в условиях теневой экономики «демократические» рейтинги не работают — это дело десятое здесь и сейчас:) Завтра «общими» усилиями экономика перестанет быть теневой, и рейтинги заработают, но на ФАКТИЧЕСКУЮ оценку каждого отдельного украинского специалиста в сфере разработки ПО это абсолютно никак не повлияет:) Вывод.Нужно больше думать о ФАКТИЧЕСКИХ достижениях наших компаний и их сотрудников, о ФАКТИЧЕСКОМ развитии каждого отдельного специалиста (в том числе и о саморазвитии), а не о том «что о нас там, на Западе думают»:)

P.S. На счет ситуационного менеджмента Александр Орехов ой как прав!

[off] 2 akhavr: МінОсвіти такая же организация, как и другие, только с государственной формой собственности и бюджетными средствами. Если эта организация видит более выгодное предложение, почему она должна отказываться?:) Если вы опять начнете вспоминать конверты, то уж лучше сразу “матерні слова”, так мы пропустим бОльшую часть флуда:) [/off]

2 ягуар: Ни с чем оценку не противопоставляю. Просто предлагаю не обсуждать то, что нельзя подкрепить фактами. А именно, финансовое и кадровое состояние украинсокого рынка IT:) А обсуждать факты о работе в конкретных компаниях, на конкретных проектах и с конкретными людьми, что мы все усешно делаем в кругу коллег и в разделе Компании этого сайта:) 2 akhavr: Такое впечатление, что ты ошибся сайтом. Советую в гугле задать поиск “державні проблеми України” и выбрать любой другой сайт на вкус:)

2 Nick Fedchik: «Ибо вряд ли какая компания тебе сообщит...». О чем и речь! Я говорю о других фактах — индивидуальных, а не «общедержавных официальных»:) Пока что только личному опыту коллег мы и можем доверять. Так будем его расширять, а не строить теории о рынке IT:). Вот о чем я.

2 Anton Naumov: «и второе, для получения крупных проектов» Вы сводите причины к направлению оффшора, а точнее аутсорсинга, поскольку полноценный оффшор требует филиалов заказчика в Украине, а это не имеет смысла для большинства европейских фирм, не говоря уже о Северной Америке.Так вот, «на Западе думают» не о статусе нашей страны, а о конкретных тендерных предложениях конкретных игроков рынка. И, судя по развитию ряда компаний, эти предложения привлекают многие довольно солидные компании и структуры на Западе."большинство украинского кода (60−70%) ужасно«:):):) Вы перечитали весь этот код?:):):) «или есть заметные подвижки на внутреннем (в первую очередь киевском) рынке? » Конечно же есть! И много. Но не в области чисто «коробочных» продуктов, хотя и такие тоже есть (и упоминаются в статье). Вы правильно подметили, что продукты Open Source ориентированы на внедрение под ключ. Так вот, к ним можно добавить и коммерческие продукты, которые разработаны украинскими компаниями под определенный нишевой спрос. И то, что они широко не рекламируются, не означает, что их нет:) Просто доход от этих продуктов базируется не на результатах рекламных компаний.

"отлично. назвать сами продукты (пусть несколько) и очертить предметную область, где они работают, Вы можете? «Могу, но это нарушит договор о неразглашении:) В качестве непрямого подтверждения могу лично подтвердить, что описанное на странице http://www.am-soft.com.ua/site... является правдой, и я принимал участие в разработке упоминаемых систем.В качестве другого примера, я могу предложить любому читателю прогуляться в любую нотариальную контору любого города Украины, и посмотреть на клиентское ПО, которое там используется. Еще с одним примером можно ознакомиться в подразделениях «Державної Виконавчої Служби» (никому не желаю в жизни сталкиваться), которые тоже есть в каждом крупном городе Украины. Это все системы класса Enterprise, в которых объединено множество рабочих мест, серверов и средств связи, которые работают в единых бизнес-процессах на всей территории страны.Таких примеров в разных секторах (не только государственном) довольно много, но рекламировать подобные продукты никто не будет. Тем не менее, они существуют, и опыт никуда не пропадет, а будет применяться как в подобных проектах, так и в других (при переходе специалистов в другие фирмы). И выход Украины как сильного игрока на международный рынок ПО — это лишь вопрос времени и... политики. Причем, политики не только нашей власти, но и Евросоюза и США. Развитие любой сферы бизнеса — довольно инертный процесс, поэтому имеет смысл заниматься отдельными конкретными улучшениями «на местах», а не обсуждать «общие тенденции рынка», на который влияют слишком много факторов.

У меня свой взгляд на этот счет.Есть 2 взаимоисключающих фактора, которые влияют на работу менеджера: 1. Нужно разбираться в проекте.2. Нужно организовывать и обеспечивать разработку продукта.Я не зря использовал термины проект и продукт — они подчеркивают две точки зрения на результат деятельности всех участников. Для заинтересованных лиц (в том числе и для разработчиков) важен продукт — результат проекта. Он дает прибыль, бонусы, решает поставленные цели. Для команды разработки (и в большей степени, именно для разработчиков) важен проект. В нем протекает жизнь команды. При прочих равных (зп/, бонусах) люди выбирают проекты поинтереснее, посовременнее, поперспективнее. И для каждого участника проекта мера заинтересованности в продукте и проекте — своя. У разработчиков (и, зачастую, тестировщиков) больше заинтересованность в хорошем проекте. У заказчиков и потребителей — в продукте. Менеджер же находится на стыке этих интересов, балансируя временем и объемом работ (scope). И именно из-за времени и объема возникает взаимоисключение.1. Если уделять слишком много внимания разработке, менеджер перестает выполнять бОльшую часть функций менеджера, и становится тим-лидом. В этом случае самый лучший вариант — выделить отдельного человека на роль тим-лида, обучить и помогать ему.2. Если уделять слишком много времени продукту, менеджер становится бизнес-технологом, а иногда и продавцом (sales). В этом случае самый лучший вариант — выделить отдельного человека на роли User Experience, Business Analysis, Sales Manager (в зависимости от объема работ по каждому направлению), и координировать его работу.Но, зачастую, для выделения отдельных людей задач маловато, да и бюджет не резиновый... В этом случае совет, данный в этой статье, выглядит привлекательным, но лично я бы более четко описал работы менеджера в разработке: 1. Участие в разработке архиректуры (Conceptual + Logical Design) в качестве ревизора или помощника архитектора на протяжении всего проекта.2. Регулярные Code Review на протяжении этапов разработки.3. Регулярное участие в тестировании UI (особенно в части Usability) на протяжении всего проекта.4. Сборка продукта и оформление поставки. Не обязательно самостоятельно, можно дизайн сборки отдать разработчику.Все остальное время (а на разных этапах проекта оно будет разным) разделить приблизительно поровну между работой с требованиями и организацией процесса.И больше НИЧЕГО. Разработка отдельной фичи — это конечно очень хорошо, но кто будет выступать рецензентом данной фичи? В большой команде (10+ человек) мы такого человека можем найти, но мы ведь не говорим о больших командах! Не стоит отвлекаться от реалий, и выдумывать «а что бы такого еще позаковыристее нафигачить». Любая фича, которая входит в релиз, должна быть качественной. Обеспечить качество фичи один человек не в состоянии (со всеми оговорками и ссылками на современные методы и инструменты разработки). А разрабатывать некачественную фичу вместо того, что бы качественно выполнять работы по управлению проектом — это неразумная трата ресурсов. Если уж так хочется оставаться «в форме» и не терять навыки разработки, никто не мешает участвовать в свободное время в другом проекте:). Конечно, всегда есть место эксперименту и всегда можно заложить время на «не основные работы», но брать менеджеру за правило то, что создает риски и может приводить к проблемам — глупо. Разработать фичу в качестве исключения (если вдруг есть на это время) — да. Закладывать в план разработку менеджером фичи — нет. Планировать разработку фичи менеджером можно лишь в том случае, когда заранее известно, что для менеджера в проекте работы мало, и он по совместительству выполняет роль разработчика. Но в этом случае менеждер автоматически обязан передать часть своих обязанностей из 1−3 (выше) кому-то другому, кто будет контролировать качество его работ, как разработчика. Для небольших коротких проектов это вполне реально:).

2 Скакунов Александр: «Мне это не интересно, и я за это не берусь — имею право. Зато есть 3−4% задач, на которые стоит «кол-во желающих = 0»"Ты применяешь условия фриланса там, где этого делать нельзя. Человек тебе описал реальную оценку с точки зрения руководителя коммерческого проекта в стартапе большой компании. Зря ты не воспринимаешь здоровую критику."Кстати, 60% людей на физическом уровне лучше заточены под рутинные операции. Женщины называются.«Эта фраза еще больше подчеркивает твою «юнность» в плане опыта работы в развитых и «продвинутых» коллективах. Женщины, несомненно, отличаются от мужчин, но они не «заточены под». Любой женщине. и любому мужчине, у которого есть зрелая и умная спутница жизни, подобная фразу равноценна фразе «я очень крутой, буду работать встречаться тока над с модными задачками нимфетками, а для рутины семейной жизни наймити ищите лохов попроще»:) Я ни в коей мере не хочу тебя оскорбить, но другого мнения о подобной фразе у меня не складывается даже после отбрасывания личного опыта.

[off] 2 Скакунов Александр: Таки понесло:) Но выражения все же стоит выбирать;) [/off] По поводу индивидуальных взглядов... Миллион леммингов, так сказать, уже статистика:) Под «рутину» (в моем понимании) «заточено» большинство best practices в нашем с вами бизнесе. Так что не стоит ее сбрасывать со счетов, хоть она и индивидуальна. А на счет сравнения мерок фриланса и мерок крупных компаний, могу лишь сказать, что если в конкретном случае эти мерки совпадают, то либо фриланс был довольно специфичным (что редко), либо крупная компания на деле являетя сборищем фрилансеров, которых объеденили некоторые сервисы (что не так уж и редко). Оба случая являются скорее исключением, потому что... это два разных бизнеса:) Они пересекаются, но они разные. И, знаешь почему они разные? Потому что, будь они одинаковыми, не было бы термина фриланс в разработке ПО:) На счет примеров «не-автоматизации» — регулярные отчеты и обновления планов по рискам — это раз, — регулярные митинги по выяснению подробностей в требованиях — это два.Для, например, архитектора это ой какая рутина! А принимать участие обязан, ибо эксперт. И еще об автоматизации. Она порой доходит до абсурда, и там, где в рутине может зародиться блестящее решение (например, устраняющее эту и другие рутины), автоматизация обрубывает всем руки. Вот такая вот правда жизни:)

P.S. Скакунов Александр, извини, что на «ты», считал, что мы уж знакомы:)

2 Kostiantyn Sokolinskyi: "И я, на пример, точно знаю, чем я заниматься никогда не буду, т.к. мне это не интересно.«А зачем мыслить черно-белыми категориями? Кто сказал, что рутина в больших проектах является определяющим фактором в оценке «интересности» и «продвинутости» работ по проекту в целом? Как раз мне опыт подсказывает, что в проектах крупных компаний участвовать интереснее, но для доведения решений до эксплуатации необходимо выполнить ряд стандартных рутинных работ. И естественно, что в больших проектах эти работы занимают бОльше времени.Никто не говорит, что работая в крупной девелоперской компании, человек обязан заниматься тем, на что не соглашался при приеме на работу:)

О чем эта статья? О том, что разработка — это не только кодирование? Ну так достаточно посмотреть требования на ЛЮБУЮ вакансию разработчика, и прочесть название скила «аналитический склад ума»...Зачем писать целую статью про очевидные вещи?

Боже, как сложно!:) У меня в подобных случаях всегда возникал вопрос... №%х%я?:) Я понимаю, что это наглядный пример (пропарсить текст, вставить ссылки).Но, блин, в каких РЕАЛЬНЫХ случаях рядовой программист (под Web, насколько я понимаю сферу применения) должен строить ТАКИЕ абстрактные построения, что бы получить от них результат? Не усложняете ли вы себе жизнь, уважаемые?:) P.S. Ответ «Да ты нихрена в этом не смыслишь! » — принимается:)

Улібнуло:) Автору, удачи и успехов в начинаниях!

"Пусть грузится долго, но красиво."Это на мобилку он долго грузится?:) Не хочу сказать ничего обидного, но нармальный канал в Интернет — это норма для развитых стран. Увы, Украина всего лишь развивающаяся:) Но лично мне хватает канала за 100грн/месяц (от Воли).

"Вся информационная часть сайта должна быть доступна пользователю вне зависимости от того, на чем и как он смотрит сайт. Это правило хорошего тона."Глупость. У сайтов, как и у реальных магазинов, офисов, и... киосков:) есть своя фокус-группа. Те реальные люди, которые используют этот сайт не случайно, а для постоянной потребности. Например, заказывают на нем дорогие домашние кинотетры и фенечки к ним. И нужно прежде всего удовлетворить эту фокус-группу (20% посетителей, приносящих 80% дохода). Современные реалии таковы, что тематические сайты ОТДЕЛЬНЫХ компаний активно используют люди, у которых практически нет никаких ограничений в Интернет (читай, скрипты не отключены). Зачем отключать скрипты на ноутбуке, который стоит 1/5 часть месячного дохода? Правильно, незачем:) Я конечно же утрирую (как и автор статьи), но в свете развития технологий и улучшения качества жизни — пусть подстраиваются под AJAX:) Быстрее купят более современную технику (чем создадут лучшие условия для технологий), заработают больше денег и не будут трястись за каждую копейку. Тогда и сайт будут использовать с большей прибылью для его владельца.

Смешно читать заявления типа «должны отрабатывать все 8 часов» на фоне з/п в компаниях, представители которых это заявляют. Пусть на минутку отвлекутся, и посчитают стоимость этих 8 часов при условии найма технического эксперта из консалтинговой компании (даже не из Большой Четверки):) Фиксированная з/п (ежемесячная + бонус) — это согласие работодателя с тем, что человек НЕ будет как робот всю неделю ЭФФЕКТИВНО и САМООТВЕРЖЕНО заниматься производственными задачами. Тем более человек творческий и развивающийся.Хотите роботов — вводите почасовой консалтинг + % от прибыли (а не от бонуса) для каждого участника проекта:) И будут каждый час отрабатывать в поте лица, что бы закрыть Work Report (ежедневный, к слову). Но и на руки получат далеко не 1−2К у.е.:) Я уже молчу про «форс-мажоры» овертаймы и «субботники»:) Честно — смешно!