Разработчики часто не любят признавать свои ошибки и всячески сопротивляются переоткрытиям тикетов или новым заведенным багам.

Как с этим бороться? Что делать, если поведение не описано, но вам очевидно, что ТАК работать не должно?

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

Сколько же этапов в онбординге?

Кто должен ими заниматься? HR, лид, команда, коллега или все вместе?

Насколько быстро давать сотруднику реальные задачи?

Надо все "разжевывать" или пусть сам разбирается?

А нужен ли онбординг на самом деле?

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

У платформодержателей множество причин для бана вашего приложения. Возможно, они есть и сейчас, просто Apple и Google их еще не увидели. 

Узнайте, что и как проверять, как избежать запрета к публикации.