Ленар Мутигуллин

Добрый вечер!

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

Если пройтись по конкретике:

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

2) После оглашения оценки по задаче всегда можно ждать справедливого вопроса "Почему так много?". Для таких случаев надо уметь (а лучше уже иметь готовую) декомпозировать задачу на составляющие, оценку для которых легче аргументировать или обосновать на основании исторических данных. Всегда можно попробовать убрать неопределенность в требованиях, если это поможет снизить оценку. Если оценка даже после уточняющей беседы (к примеру заказчик может более четко описать задачу) не изменилась, то можно попробовать предоставить варианты в духе "Если мы откажемся от фишки X, то я сделаю эту задачу на два дня быстрее", чтобы дать понять, что оценку можно менять, согласившись на урезание требований.

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

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

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

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

7) Неадекватность может встретиться всегда. Главное не отвечать на отсутствие логики или хамство тем же. Конктетизируйте и структурируйте свою позицию. В случае, если диалог заходит в тупик, говорите, что вы в данный момент не видите решения сложившегося конфликта. Можно предложить менеджеру два варианта: первый - сформулировать свой вариант решения проблемы. Если не поможет - идем ко второму варианту. Второй вариант - эскалировать решение вопроса на руководство или на любого другого сотрудника, имеющего право решать подобные вопросы.

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

Это не серебряная пуля, но в принципе решает часть задач, иногда можно полностью отказаться от нативной разработки. Хоть тема и не нова, но обсуждать имеет смысл только решения, которые появились относительно недавно (crosswalk, intel xdk, framework7). До этого всё было тормознуто и html5-приложения в итоге заработали дурную славу.

Краткий ответ: Да, html5 приложение на данный момент уже может заменить нативное в ряде случаев, так как при использовании правильных технологий оно получится достаточно близким к нативному.

Есть тонкости. Многие думают, что Cordova/PhoneGap это и есть тот самый фрейморк в котором и кроется секрет производительности или тормозов итогового приложения. На самом деле есть 2 разные по сути вещи:
Cordova/PhoneGap - это фрейворк, который соберет html5 приложение в apk и т.д. По сути это просто конструктор, никак не влияющий на производительность итогового приложения. Он позволяет взять html5 приложение, добавить плагины, для работы с камерой/gps/рекламой, и в итоге получить аналог нативного. Но так сложилось, что почти все публичные примеры из коллекции phonegap тормознутые, и поэтому многие так и думают, что html5 тормознутые.

Дело в том, что есть фреймворки вроде cordova, а есть html5 фреймворки и это разные вещи, и их нельзя ставить в один ряд. Сама по себе cordova не тормозная и не быстрая, она работает так и только так, как работает html5-приложение (которое запросто можно запустить просто в браузере, и нажав в браузере "добавить на рабочий стол", оно будет работать как автономное приложение). Соотвественно, если html5 фреймворк быстр и отзывчив, то разница с нативным приложением будет незначительна.

Второй момент. Так как html5 приложение, это лишь html+js, и запускается он внутри webview, то скорость приложения так же зависит от скорости движка webview. Допустим, на ios с этим все хорошо, а вот на андроид с этим хорошо только начиная с 5.х версий. На старых версиях андроида очень тормозной webview.
Эту проблему с тормозным webview вполне успешно решила Intel представив проект crosswalk. При использовании crosswalk стандартный webview заменяется на последнюю версию chromium, что означает поддержку новым фич, больше плавности, скорости и т.д.
Само собой, чем свежее crosswalk, тем быстрее и стабильнее работает итоговое html5 приложение.

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

Есть 2 очень быстрых html5 фреймворка (по субъективным тестам, framework7 выигрывает в скорости и плавности), это framework7 и ionic - они решают многие проблемы тормозов, задержек, залипаний присущих стандартному использованию js.
Соотвественно, например, используя framework7, время отклика нажатий, реакции на свайпы и т.д. будет аналогично тому, что и в нативном приложении. Оба вреймворка содержут набор фич, реакций на типичные для приложений событий, а так же набор всех стандартных и расширенных компонентов, которые потребуются при разработке, и которые подключаются парой строчек в html файле в нужном месте. Они уже имеют встроенные стили, в итоге все компоненты и приложение в целом выглядит как нативное (один в один) ios8 или material design, никакой инородности. При этом их легко настроить через css.

Чуть подробнее можно посмотреть в статье "Быстрое кроссплатформенное HTML5 приложение на Framework7" - habrahabr.ru/post/257889 или аналогичных (про ionic например) там же
В итоге, на момент написания статьи, на гаджетах 5 летней давности всё работает примерно на 10-15% хуже чем аналогичное нативное решение. Если сейчас перекомпилировать со свежим crosswalk (в intel xdk, кстати, это делает даже совсем просто, достаточно нажать build и выбрать crosswalk), то разница будет еще менее заметна.

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