Так уж и быть задам вам самый главный управленческий вопос:
7. Критерии прохождения в Appstore вам были полностью известны до начала проккта?

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

Наконец-то хоть немного вопросы по теме.

> Есть ли у нас аккаунт в аппсторе? Есть ли незакрытые по последним публикациям незакрытые споры?
Да, более 3х лет, зарегистрирован на US (голова конторы там). Споров нет, весь предыдущий софт без проблем, апрувы редко занимают больше 5 дней, тк имеется credibility.

> Нет ли в дизайне нашего приложения элементов, которые могут вызвать вопросы при проверке приложения в аппсторе?
По большому счету - нет. Есть логотипы из public domain, но в предыдущих продуктах они тоже были.

> Успеем ли выложить с учётом рождественских праздников?
Риски учли заранее. Было заложено 10 дней на апрув. Предудыщие занимали 3-5 дней. (Да, раньше все было побыстрее).

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

Всем привет. Если кому интересно пройти онлайн тренинг по проектному управлению пишите в личку.  Курс 2 месяца 80 % практика.

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

В истории с Appstore, я правильно понимаю, что знание предметной области от лебедя не защитило?

там нехватило знаний "предметной области". Общие знания по PM, PdM, а также спец. знания в ИТ и тех. части - все было, опыт разработки B2C продуктов с 0 был, просто есть моменты, которые способны вырасти в лебедя и они особенные даже не просто для индустрии, а для ее под-доменов.
Тут ни о каком успехе речь не может идти, если ПМ обладает только общим набором знаний.

> Если технический релиз пройден, вопросы по публикации сняты (хотя я бы ещё почитал на сайте аппстора причины, по которым можно получить reject, вдруг там какое-то условие не выполняется). то  может с Заказчиком не утрясли дату приёмки?
Продукт наш, мы сами были заказчиками, так что тут вопросов нет.

Мы тоже заранее подготовились к ревью и у нас был опыт его прохождения, так как и успешных аппеляций.
И даже предыдущий продукт из этой же серии успешно прошел ревью и дошел до top50 ipad US.
Что, впрочем, не защитило проект от фейла в этот раз.
Проблема существует в субъективности процедур ревью - тонкие моменты вроде использования public domain символов остаются на решение конкретного ревьювера - даже перерисованные заново. Это и стало блоком, хотя еще раз отмечу - предыдущий продукт успешно прошел ревью и уже более полугода был доступен на рынке. Официально обновлялся два раза.

Ок, спасибо, интересный кейс.

Предрождествеские публикации в аппстор на 100% зависят от конкретного индуса, который будет ревьюить

Так и случилось.
Внутри компании существовало предубеждение о "ios first" - продукты старались выкатывать сначала на ios, потом на android, хотя никаких формальных предпосылок к этому не было. Предыдущий PM не видел рисков, может исповедовал "универсальный" подход.
К сожалению, для текущего проекта этот риск тоже не прошел переоценку и остался без внимания.
После потери инвестиций в размере 320ч х 5 сотрудников компания получила урок и пересмотрела релизную политику - все текущие проекты были переориентированы на тестовые релизы на андройд (в среднем 3-8 часов на автоматический апрув). Релиз на iOS в плановом порядке после обкатки на Android.

А случае Ярослава, полагаю, он для этапа "публикация в appstore" пригласит в команду отдельную экспертизу, которая будет прищвана обозначить все эти риски.

Эти риски и без экспертов очевидны. Если где то в приемке есть место суъетивизму это самые опасные риски.
Проект вообще нужно планировать ретроспективно от конца.

Эти риски очевидны, когда ты в них хоть раз уперся

Разве вы в бытовых ситуациях не упирались в риски принятия кем либо решений по субъективным мотивам? В проектах так же.

шах и мат, универсалы

Не не, погодите, Ярослав ещё не победил Вас в споре)

Частенько вспоминаю анекдот. Мама, мама! Я научился считать! -Да? И что же ты считаешь, сынок? - Я считаю всех говном!

можно политкорректно распределять всех по бритве Хэнлона (не знаю, как это визуализировать, но суть должна быть ясна)

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

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

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