MyPlainText

Этот пост - продолжение предыдущего , который был посвящен приложению Places. Сейчас разработка подходит к концу, а подбор контента только начинается.  О контенте говорить пока нечего, а вот в разработке есть ряд доработок, которые я, скажем так осознанно не предусмотрел заранее, т.к. понятно что идея и дизайн будут видоизменяться постоянно по ходу творческого процесса разработки) Итак, что нового: 1) Иконка приложения переработана в более яркую и контрастную форму на сером фоне и        добавлена тень, так ближе к гугловским иконкам. 2) Игровой экран, который не даёт отклика пользователю, верный ли он дал ответ н вопрос - это провальная идея. Добавлены уведомляющие тосты а для них нарисованы иллюстрации: 3) Заглушки для фото, пока оно подгружается, и на случай ошибки подключения к интернету.

Решил, наконец написать свое первое приложение ради забавы и из интереса. Идея: викторина по достопримечательностям и интересным местам городов России (для начала).  Цель: Сформировать свой образ каждого города с помощью набора красивых интересных фоточек, как в советском союзе были наборы открыток, только в этот раз все в смартфоне и в форме игры. Вот предположительные варианты иконок прилки: (скорее всего левый верхний будет взят) Вот главный экран, который задает настроение: (тут позаимствованы фото знакомых и переведены в ч/б. На определенном варианте пока не остановился) Экран выбора города пока в двух вариантах - упрощенный и усложненный. Пока думаю остановиться на упрощенном: Далее более-менее стандартный игровой экран: На экране результатов я постарался сделать радующие глаз линейные иллюстрации: А потом и состряпал экран "О приложении":  На этом все приблизительный черновой вариант дизайна готов. Через неде

В новом сообщении предлагаю познакомиться с динамично развивающимся нынче проектом "Едадил". Для начала - что это  Едадил - это аггрегатор скидок в продуктовых супермаркетах(ну и не только продуктовых). Мобильное приложение, которое позволяет найти скидки в каком-либо супермаркете на какой-либо продукт с помощью гаджета. Идея хороша во всех отношениях - прозрачная схема монетизации + теоретически удобный инструмент для поиска выгоды для домохозяек (да и не только домохозяек, но и людей, которые покупают еду в скпермаркетах). Идея не нова. Первенство в такого рода проектах принадлежит скорее всего проекту MySupermarket в Англии - прекрасный ресурс на мой взгляд с интеграцией службы доставки, подключением рекламы сельского хозяйства - как производителя сырья и прочими интересными идеями и фичами. Есть ещё ряд аналогов на Украине типа такого  http://mysupermarket.org.ua/ А также были некоторые попытки создать нечто такое и раньше в России и с названием

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

Анализ и расстановка приоритетов рисков - это следующие после "Определения" этапы в цикле управления рисками . Сам анализ предполагает 2 этапа: Определение вероятности свершения каждого риска. Можно использовать набор величин: 10%, 25%, 50%, 75%, 90%. Вполне естественны затруднения на этом этапе даже при выборе из пяти дискретных значений. Для достижения объективной оценки вероятности свершения можно использовать такой прием: проводить оценку вероятности свершения рисков всей командой или частью команды. Сначала проводить оценку рисков индивидуально и анонимно. После чего обсуждать результаты, приходя к общему мнению.        2. Оценка воздействия на проект в случае свершения риска.В простейшем случае предлагается оценка от 1 до 5, где 1 - незначительное 2 - малозначительное 3 - среднезначительное 4 - значительное 5 - сильнозначительное. В более сложных вариациях возможны варианты оценки воздействия риска на проект по следующим 4-м показателя

Определение рисков проекта - первый этап, с которого начинается процесс управления рисками. При определении рисков следует понимать, что есть общие риски и специфические , завязанные на конкретном проекте. Общие риски присущи практически любому проекту разработки ПО, например, изменение требований заказчика, потеря ключевого члена команды. К специфическим можно отнести те, которые зависят от сферы, в которой разрабатывается проект, от исполнителей, технологий. Также необходимо уметь выделять риски по следующим трем группам: проектные  риски, риски продукта , бизнес риски. Проектные риски - те, которые влияют на ресурсы и работу проекта. На бюджет или на команду, например. Риски продукта - те, которые влияют на конечное качество продукта Бизнес-риски - те, которые могут повлиять на соответствие продукта бизнес-требованиям и бизнес-стратегии. Далее будет приведен ряд базовых факторов, которые следует учитывать при управлении рисками.

Предыстория С началом работы над крупным проектом в нашей небольшой команде встал вопрос о том, чтобы планировать итерации разработки, выбирать задачи и оценивать их объёмы. Кроме бэк-энд разработчика, пришедшего вместе со мной, никто такого опыта не имел: ни дизайнер, ни верстальщик, ни фронт-энд разработчик - отсюда и результат: 1-ая итерация клиентской разработки затянулась на 2 недели, относительно оценки. А 2 недели эти сложились очень быстро: - Сперва дизайнер что-то не учел на пару-тройку дней - Эти же пара дней сказались на работе верстальщика с дополнительным коэффициентом, ввиду того, что сверстать более трудоёмко - Ну и в завершение - Front-end разработчику приходилось ждать вёрстку  Чтобы оценить: 2 недели задержки при, скажем, 1000 руб/час это 80 000 руб. /*1000 руб/час взял условно*/ После таких  грустных расчетов я вспомнил о суперсиле риск-менеджмента! Очевидно, что стоило изначально учесть неопытность членов команды в таком компо