Ну, должен сказать, что для ИТ отрасли современная система образования не готова. Сужу, как выпускник Киевского Политехнического. Хороших управленцев можно подготовить из современных разработчиков. Я, например, работал около 3 лет разработчиком. В рамках собственного опыта часто становился тимлидом. На предпоследнем месте работы, а это была средняя аутсорсинговая компания, понял, что самой частой проблемой в жизни наших проектов был именно плохой менеджмент. Сейчас я нарабатываю опыт как ПМ. С уверенностью могу сказать, что ели у вас в штате сотрудников есть лиды или старшие разработчики, или даже мидлы, у которых коммуникативные навыки на высоком уровне, попробуйте дать им литературу по менеджменту проектов, попробуйте дать им возможность пообщаться с клиентом напрямую, возможно у вас под носом сидит ваш следующий толковый ПМ, а может быть даже и КоммДир ;)

Согласен. Кейс абсолютно реальный. Но ничто, например, не мешает в рамках услуг бизнес анализа/предпроектного исследования предоставлять также и последующее ведение проекта с выбранным Исполнителем проекта. Но, в моем опыте есть случаи, когда заказчик приходил с настолько детальным ТЗ, что необходимости в доступе к «мозгу» не было. Садись, оценивай время, бей на задачи и работай. Такое тоже бывает.

А разве вне СНГ по-другому? Мне кажется, эта проблема относится ко всей индустрии.

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

если бы это было прибыльно, подобных компаний было бы полно.

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

Результатом любого предпроектного исследования становится документ — техническое задание. Во всяком случае в моей идеальной вселенной. С детальным ТЗ, которое однозначно описывает моменты, критические для бизнеса, можно смело направляться к исполнителям с вопросом о сроках и стоимости.

Основная проблема современной разработки, а точнее особенность рынка СНГ состоит в том, что разработчикам приходится делать много Предположений, что само по себе плохо, т.к. жизнь показывает — в подавляющем большинстве случаев Предположение оказывается неверным. Для того, чтобы от той проблемы избавиться, необходимо тратить достаточно большое время на предпроектное исследование, а это несет за собой большие риски как для Клиента, так и для Разработчика. Ни одна из сторон не готова брать на себя эти риски и связанные с ними. Потому зачастую мы имеем как результат проект, который не попадает ни в сроки, ни в бюджет, ни в ожидания заказчика/пользователей. Это лично мое мнение.
В качестве отступления хотел бы помечтать и отправиться в то время, когда будут существовать компании, предоставляющие услуги предпроектного исследования для заказчиков ИТ сферы. Тогда бы количество успешных проектов могло бы вырасти хотя бы раза в 2 )) что уже очень немало.

Я киевлянин и знаком с ситуацией в своей городе, применять мое мнение в для работодателей из других городов будет скорее всего ошибкой.
Первое, что хочу заметить про обучение. Не стоит уделять чересчур много времени теории. Знания (теоретические) без навыков (практического применения знаний) ничего не стоят. Так что всегда старайтесь закрепить то, что только что прочитали. И желательно десятком разнообразных задач, а не одним тестовым примером.
Второе, что касается самих вакансий. Есть компании, у которых вакансия джуниора означает поиск парня, на которого можно повесить стирку грязного белья. У них джун означает уровень ЗП, а не квалификацию соискателя. Подобные компании — отличное место для быстрого обучения в боевых условиях и последующего поиска адекватного работодателя.
Компания, которая осознает действительный уровень знаний джуниора никогда не будет требовать от него уверенного знания какого либо фреймворка или большого опыта работы (вакансии джунов с требованием уверенного использования принципов ООП и опытом разработки на РНР 1-3 года вызывают только улыбку). В подобных ваш конечный уровень определяется уже не столько знаниями, соклько навыками. Да, на одних навыках вы сможете вырости только до мидл уровня, синьер требует от вас хороших теоретических знаний и навыков использования этих знаний, но работая у работодателей второго класса вы сможете получить все необходимые знания и навыки. И самое главное, вы будете мотивированы оставаться работать и рости профессионально именно у них. К сожалению, подобных компаний не так много, как хотелось бы.

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

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

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

если пример претендует на нечто действительно рабочее, а не «вот как можно сделать для моего девайса», то больше, чем 3- я бы не поставил. действительно много велосипедов, нет адаптации под разные экраны, переопределение onMeasure будет работать не всегда правильно. в общем, как то не очень.

я — андроид разработчик, который очень скучает по ГР. С удовольствием помогу в тестах/разработке.

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

это Вы не совсем поняли смысл моих слов. я знаю, что пока Студия — только превью. Но уже в превью она обещает быть очень приятной. Потому я сожалею, что в ней еще есть всего пара багов, которые мешают мне сменить IDE. Как только их устранят, я с радостью буду пользоваться софтом, который доставляет меньше страданий, чем Эклипс. Ничего плохого не хочу о нем сказать, но Студия действительно получается лушим продуктом.

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

Вот тут как раз и вся беда.

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

По поводу «новой крутой модели» хохма в том, что она как раз нужна для реализации бизнес логики, которую на текущей модели реализовать просто нереально, она не заложена в модель. Вот так и живем. Мобильное приложение, которое занимает в данный момент 240 Мб в памяти, выполнять можето только 2/3 из бизнес задач, но рюшики важнее.

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

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

Хочу поделиться своим грустным опытом в Agile.

В данный момент я являюсь ТимЛидом в одном из многих стартапов. Как и другие, наш стартап начинался с идеи и пилотной альфа-версии для демонстрации идеи инвесторам. После нескольких итераций идея приобрела некий приемлемый для инвесторов вид и было дано добро на развитие. Новоявленные продакт менеджеры и инвесторы добавляли все новые и новые фичи в проект и, как водится в СНГшном бизнесе, просили результаты работы «на вчера». В этот момент случилась первая и решающая ошибка команды разработчиков(к которой, на тот момент, относился и я сам). Они начали внедрять новые фичи не задумываясь о модели и не документируя свои решения. Тоесть для каждой задачи выбирался подходящий по форме и размеру костыль и подставлялся, потому что инвесторы хотели увидить эту фичу еще вчера.

Прошел год такой разработки. Все дедлайны были провалены, часть людей ушла из проекта, часть добавилась. Я стал тимлидом. Один из менеджеров решил, что для повышения эффективности команды ей стоит работать, придерживаясь Scrum`а. Он был введен. И вот, после 10 спринтов, вся команда начала понимать, что велкикий и могучий Скрам не помогает нам работать. Потому что нет костяка(читай ТЗ), который можно было бы гибко менять в заисимости от отклика юзеров. Овнер(он же менеджер, предложивший Скрам) продолжает требовать от команды новых костылей и не хочет обращать внимания на глобальные проблемы модели приложения, команда продолжает пилить гири костыли. Каждый день я жду новых падений модели-инвалида и пытаюсь убедить Овнера, что нужно приостановиться и обновить модель.

Мораль сей басни такова: гибкая разработка — это круто, но каждому необходимо понимать, когда ней можно начинать пользоваться, а когда еще рано.

Согласен, но мои слова были именно о туториалах, подобных этому.

Я начинал программировать под андроид руководствуясь поначалу только гуглом. Мои сложности заключались в том, что зачастую я сталкивался с проблемами, которые выходили за рамки «Hello туториалов». С классическими ситуациями я справлялся без книжек и гугла, а вот исключения приходилось решать очень долго. И причиной этому было то, что мне, неопытному программисту, гугл выдавал наиболее релевантные данные, коими, по его мнению, были именно примеры для чайников. А правильно спрашивать я еще не умел.

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

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

Я не пытаюсь ругать автора. Много раз после решения очередной «очевидной» проблемы я хотел написать туториал по решенному вопросу. Но кахждый раз смелости и таланта не хватало. Я просто призываю автора тратить свое время на что то более полезное.