28 ноября 2017
Роли в команде разработки ПО
Андрей Подкин
Часто Иногда при обсуждении недостатков приложений пользователи говорят, что разработчики поленились сделать хорошо. Но кто такие разработчики приложений? Давайте попробуем разобраться, какие роли есть в команде разработки.
А точно все они есть?
В принципе, для того, чтобы сделать простейшее приложение, достаточно одного-единственного программиста. Но при возрастании сложности и увеличении сроков разработки кому-то волей-неволей придется исполнять те или иные роли, даже если они явно не выделены (в виде должностей или как-то еще).
Проект
Важный момент разработки программного обеспечения (ПО) заключается в том, что эта самая разработка ведется в рамках проектов. Т.е. очерчиваются сроки, желаемый результат и бюджет проекта (сюда же обычно включаются и людские ресурсы, ведь людей нанимают за деньги и от количества денег зависит, сколько разработчиков и какой квалификации можно нанять). А теперь давайте попробуем рассмотреть, кто же участвует в проектах разработки ПО.
Команда программистов
Собственно, те люди, которые придумывают и реализовывают приложение. Они:
- придумывают архитектуру приложения;
- пишут код;
- консультируют других, как писать код;
- рецензируют код за другими;
- пишут автоматические тесты (по крайней мере, их часть — модульные тесты);
Без написанного и скомпилированного кода приложения не будет. Именно поэтому совсем исключить программистов нельзя. Даже если какие-то приложения создаются в простом визуальном конструкторе, то это тоже своего рода программирование.
Именно программисты зачастую принимают решение, как конкретно будет реализована та или иная функциональность в приложении. И если функциональность реализована плохо, то значительная часть вины может лежать на программистах. А может и нет, поскольку финальное слово в принятии решений принадлежит не им.
Тестировщики
Это те люди, которые проверяют, корректно ли приложение работает. Причем корректно — не значит удобно для пользователя. Тестировщик может написать замечание к удобству использования, но его первоочередная задача — убедиться в том, что приложение работает согласно требованиям и спецификациям.
Тестировать приложения можно как вручную, так и при помощи автотестов (например, программно нажимать кнопки и проверять, какие экраны открываются).
При отсутствии в команде разработки явно выделенных тестировщиков их функции обычно передаются программистам. При этом считается, что программист не может корректно протестировать то, что он разрабатывал сам, и потому проводится перекрестное тестирование (Вася тестирует то, что делал Петя, а Петя — то, что делал Вася). Другой способ экономии на тестировщиках может заключаться в том, что опытный специалист привлекается только для написания плана тестирования, а реальное тестирование (на большом «зоопарке» устройств) производят начинающие тестировщики, которые «стоят» намного дешевле.
Если в приложении есть явная и незамысловатая ошибка (кнопки в калькуляторе иногда не нажимаются), то часть вины в ней лежит на тестировщиках (они что-то не проверили).
Дизайнер
Это человек, который определяет, как будет выглядеть и как будет вести себя приложение. Взаимное расположение элементов, схема перемещения по экранам, анимации — все это должен продумать дизайнер. Если приложение большое и сложное, то дизайнер может быть и не один. Или, например, один из дизайнеров может только рисовать интерфейс, а другой — глобально продумывать всю концепцию взаимодействия с пользователем.
Дизайнер есть не во всех компаниях, занимающихся разработкой ПО, поэтому если приложение не сулит коммерческого успеха, то появляется соблазн сэкономить на привлечении профессионального дизайнера (и тем более целой команды), передав его обязанности программистам. И может получиться не так уж и плохо, если программисты достаточно опытные и понятия «usability» и «user experience» для них — не пустой звук.
Иногда дизайнер совместно с программистами несет ответственность за часть ошибок в приложении: бывает, что реализовать придуманный дизайн довольно сложно, а при возрастании сложности увеличивается и вероятность совершения ошибок. И, конечно, все отзывы «неудобный интерфейс» — это камни в огород дизайнера.
Заказчик или владелец продукта
Это человек, который определяет весь ход создания и развития продукта. Он принимает решение, что должно быть сделано, оценивает, соответствует ли реализация концепции продукта или нет. Например, программисты говорят ему: «Для реализации этой штуки нам потребуется два месяца. Или можем использовать кучу сторонних библиотек и сделать все за неделю, но тогда объем приложения увеличится на 30 Мб». Владелец продукта может сказать: «Еще 30 Мб? Это совершенно неприемлемо» или «У нас релиз через месяц, делаем как можно быстрее и запускаемся». И он же несет ответственность за направление развития продукта. Если вы читаете отзывы: «Зачем испортили такое хорошее приложение? Теперь оно вообще стало ни о чем», знайте, именно владелец продукта определил такую судьбу проекта.
Разница в названиях роли проистекает из типа компании. В продуктовой компании (которая разрабатывает свой внутренний продукт) назначается владелец продукта. При заказной разработке выделяется представитель заказчика, который будет взаимодействовать с разработчиками.
Может ли проект разработки обойтись без этого человека? Проект — может, а продукт (приложение) — нет. Кто-то все равно должен понимать, для чего это приложение разрабатывается и как оно должно существовать и развиваться в дальнейшем.
Руководитель проекта
Человек, который руководит всем этим безобразием всей этой командой. Отслеживает сроки выполнения задач. Оперативно реагирует, если начинаются проблемы с качеством. Мотивирует команду работать более эффективно («выбивает» премии, заказывает пиццу, и прочая, и прочая). Вместе с владельцем продукта принимает решения, когда возможны альтернативные варианты при выборе развития продукта в ходе разработки. Если проект очень большой и сложный (что все-таки для мобильных приложений редкость), то он может разбиваться на несколько подпроектов, и у них могут быть свои руководители, а в помощь руководителю проекта выделяется администратор проекта, который занимается большей частью «бумажной» работы: ведет протоколы совещаний (фиксирует принятые решения), рисует график прогресса проекта (например, «сгорание задач»).
По статистике, только малая часть проектов по разработке ПО завершается в срок с установленным уровнем качества и в рамках первоначального бюджета. Если что-то пошло не так, именно руководитель проекта в конечном счете принимает ответственность за то, чем придется жертвовать: выпустить продукт позднее, исправлять ошибки при помощи обновлений или выбить побольше денег (например, чтобы отдать часть разработки другой команде за отдельные деньги).
В небольших проектах с опытной командой программистов и тестировщиков можно обойтись и без явно выделенного руководителя проекта. Тогда обычно его роль исполняет ведущий программист — тимлид (калька с английского teamlead — лидер команды).
Заинтересованный топ-менеджер
В литературе по управлению проектами его обычно называют спонсором проекта. Для компании, разрабатывающей ПО на заказ, он не важен. И без него всем очевидно, что проект дает: это те деньги, за счет которых и живет компания. Но в компании, которая разрабатывает ПО внутри себя (это может быть и продуктовая компания, и компания, разрабатывающая приложения для своих внутренних потребностей), все может быть сложнее. Конкретное приложение может быть не столь важно для компании, размер и структура компании могут вносить свои коррективы (кто-то может решать свои личные задачи, например, по карьерному росту, за счет конкретного проекта). Поэтому становится очень важным, чтобы был топ-менеджер, который «болеет» за продукт и продвигает его. В этом случае при возникновении проблем команда разработки всегда может обратиться к нему, рассказать о проблемах и получить необходимые ресурсы. Типичный пример: премии за успешную работу. Если команда действительно старалась и выпустила приложение в срок с заданным качеством, руководитель проекта может обратиться к спонсору проекта для того, чтобы он инициировал выделение дополнительных средств на премию.
Заключение
Теперь вы знаете, кто есть кто в команде разработки приложений. И если вам придет в голову мысль разработать приложение под Android или iOS, вы будете знать не только о том, что для этого надо, но и о том, каких людей нужно найти.
Так же не лишним бывает человек, который стоит между командой разработки и пользователями. Тот который берёт на себя весь негатив с обеих сторон. Мастерски переводит с обезьяньего языка на человеческий и обратно. Имеет не плохую интуицию и начальные навыки телепатии. Тратит больше всех нервов. Денег получает меньше всех вышеперечисленных. Впрочем как обычно 🙂
Ну, если шагнуть за пределы команды разработки, то можно вспомнить и не одного человека, а много разных 🙂
О, вот человек понимает в техподдержке!
А где аналитик, который а) хотелки владельца продукта превращает в понятное для разрабов описание; б) убедительно отметает всякий нереализуемый или бесполезный бред, который придумывает заказчик/и? Без аналитика разрабы такое наваяют, которое в народе называется «говноприложением».
Стейкхолдер — это не только топ-менеджер. Топ-менеджер, как описано в тексте, это спонсор проекта. А стпейкхолдер — это любой, который имеет непосредственное или даже косвенное отношение к проекту, может оказать отрицательное или негитивное влияние, которого нужно обязательно привлекать или как можно дальше держать — это всё стейхолдеры.
>> А где аналитик
Потерялся, поскольку я очень давно видел такого последний раз в команде мобильной разработки 🙂
>> Стейкхолдер — это не только топ-менеджер. Топ-менеджер, как описано в тексте, это спонсор проекта.
Пожалуй, что да. Тут получилась некоторая путаница с терминологией. Спасибо за дополнение.
совершенно не упомянут частный, но частый случай, когда мобильное приложение разрабатывается, как клиент к веб-сервису, в рамках разработки этого самого веб-сервиса. роли-то те же, но их взаимодействие может быть немного другим: как правило, за бэкенд (серверную сторону), веб-морду и мобильного клиента отвечают несколько разные люди.
ну и технического писателя с аналитиком вы где-то по дороге потеряли.
Я, конечно, видел технического писателя на мобильных проектах, но обычно это какая-то экзотика. Разумеется, за исключением случаев, когда мобильное приложение — всего лишь один из различных клиентов для корпоративной системы. Тогда — да, на мобильный проект тоже дают «техписа».
Про бэкенд не хотелось углубляться. Тем более, что обычно это бывает отдельный (от мобильного) подпроект.
Да одного программера хватит
Я верю, что ведущий аналитик не обидится на то что одноименных ему специалистов забыли чуть более чем полностью. Хотя упоминание вскользь неработающего калькулятора, несомненно исправляет полит.ситуацию.
Коммент, что в мобильной разработке из не встречается я читал. Возможно это многое объясняет [многозначительность].
Статья нужная, спасибо!
Понятно, что мобильное приложение — это не промышленная SCADA и тут архитектуру могут придумать и разработчики, но архитектора приложения куда-то потеряли.
Я упомянул архитектуру в команде программистов. Обычно это в мобильной разработке так бывает.
Андрей, можно еще было упомянуть стадии проекта.
1. Энтузиазм.
2. Шумиха.
3. Неразбериха.
4. Паника.
5. Поиски виновных.
6. Наказание невиновных.
7. Награждение непричастных. :))
8. Презентация.
9. Опохмеляция.
последний пункт — достоин аплодисментов!)
Наличие Product owner — это не признак продуктовой разработки, а знак того, что используется гибкая методология скрам, он может быть и при заказной разработке, причем даже необязательно на стороне заказчика
PO есть и без гибких методологий. Для любого продукта всегда есть человек, который отвечает за оценку того, а то ли вообще было сделано. Называться, конечно, может и по-другому.
гибкая методология не значит скрам! Даже в новом PMBoK очень много из Agile переняли. Работа PO даже в методологии становится все более важным элементом
В идеале так. А в реальности?
Например: Как часто НЕдизайнеры с правом голоса, считая себя понимающими, лезут в дизайн? Кого на самом деле винить за интрефейс?
Как часто дизайнеры сами понимают usability и user experience? Точнее, что они, не просто вИдение, а научное измеряемое понятие,
характеризующееся определенными метриками? Уж очень часто видна неоптимальность. Не нравится/ненравится, а именно неоптимальность — время, тапы, расстояния.
Кто отвечает за появление в программе графики сверхвысокого разрешения, которая удваивает размер приложения? По логике — заказчик, который отвечает и за появление библиотеки в 30мб, а на самом деле? И почему в одном случае один, а в другом другой?
Кстати, считаю, что роли точно все есть. Всегда. Независимо от сложности проекта. Просто иногда один человек выступает в нескольких качествах. В пределе — во всех. Театр одного актера. Но роли никуда не деваются.
>> А в реальности?
Зависит от конкретного случая. Например, заказчик может разрешить команде использовать внутреннего дизайнера, а может настоять на своем (внешнем).
>> Как часто НЕдизайнеры с правом голоса, считая себя понимающими, лезут в дизайн?
Ну я — постоянно лезу 🙂
Иногда меня отпинывают, иногда исправляют и говорят «спасибо».
>> Как часто дизайнеры сами понимают usability и user experience?
Всяко бывает. Тут ведь еще штука в том, что заказчик может дать время и бюджет только на рисование макетов. Очевидно, что делать хорошее исследование UX за свой счет (и по времени и по деньгам) команда не будет. Максимум — могут что-то подсказать исходя из своего опыта.
Так вы лезете в дизайн без права голоса.
А по остальному, значит нельзя за интерфейс кидать камни в дизайнера, за ошибки в тестировщика, за реализацию функциональности в программиста. Все камни надо кидать в заказчика. И это правильно. Правило единоначалия и ответственности.
>> Так вы лезете в дизайн без права голоса.
Я стесняюсь спросить, кто вам это сказал?
>> Все камни надо кидать в заказчика.
Который очень часто не понимает многого и в процессе, и в технологиях.
Вы сами. Что окончательное решение принимаете не вы. Вас либо отпинывают, либо благодарят.
То есть виноватых нет? Исполнителям дали недостаточно времени/средств, значит это не их вина. Заказчик не понимает, значит это не его вина. Так не бывает! И если первое это объективно, то второе миф. Не понимаешь — разберись. Не можешь — найми специалиста. Не знаешь как нанять — обратись к тому кто знает. Но отвечает перед клиентами все равно заказчик приложения.
>> с правом голоса
>> Что окончательное решение принимаете не вы.
Каким образом у вас право голоса превратилось в право принятия окончательного решения?
>> То есть виноватых нет?
Есть. В разных случаях — разные люди могут быть виноваты.
>> Не понимаешь — разберись. Не можешь — найми специалиста. Не знаешь как нанять — обратись к тому кто знает.
Ну да, если вас плохо постригли в парикмахерской по рекомендации друга, которого стригут хорошо, то это только ваша вина. Не разобрались.
Это уже детали, да и пример не очень хороший. Ключевое — исполнитель отвечает только перед заказчиком, а перед клиентом отвечает только заказчик приложения. Это бизнес. Никого не волнует, что он знает и с кем взаимодейтсвует. Не можешь, не знаешь — не входи. Если решил войти — отвечай.
Если вы купили приложение и заключили некий договор (это обычное дело, например, для B2B), то конечно. Если вы скачали бесплатное приложение, перед вами вообще никто ни за что отвечает. А фраза «кто виноват» имеет характер чистого любопытства (для тех, кому интересно, почему так получилось). «Заказчик всегда виноват» — типичная фраза разработчиков, которые просто желают переложить всю ответственность с себя.
То, что в бесплатном приложении никто не отвечает, это еще один миф. Потому что бесплатных приложений не бывает. Просто плата и ответственность опосредованная. Клиент платит не деньгами, а своим временем, вниманием, персональными данными или еще чем. Которые владелец приложения, уже конвертирует в деньги.
И как раз ваша статья, желание переложить ответственность на тестировщиков, дизайнеров и прочих разрабочиков. Только почему сразу в
комментариях: ах, а если им недодали времени и бюджета? Вы уж определитесь.
Повторю, разработчики тоже отвечают, но не перед клиентом, а перед заказчиком. Там другие резоны и кухня, те же время и деньги, которые снаружи неизвестны, да и не должны интересовать. За жизнь программы, от идеи до снятия с поддержки, будут это лавры и бабки или камни с тапками, отвечает ТОЛЬКО заказчик.
Реквестирую еще одну статью. Роли в бизнесе мобильного ПО. Вот там и будут, все связи и ответственность между участниками.
Некоторых заказчиков просто закидывать нужно, не то что отдельные камни кидать.
Как часто дизайнеры сами понимают usability и user experience? >>> 80%+ дизайнеров или не знают его вообще, или как упомянули — максимум знаю пару-тройку паттернов. При этом сильно противятся аналитике и построению интерфейсов исходя из статистических данных и моделей.
Тут ведь еще штука в том, что заказчик может дать время и бюджет только на рисование макетов. Очевидно, что делать хорошее исследование UX за свой счет (и по времени и по деньгам) команда не будет. >>> И да и нет. Если дизайн идет от заказчика или бюджет совсем маленький, то да, согласен. Но в остальных случаях это вина PM/PO, что такую услугу не включили в обязательный список.
Что мы узнали о компании Андрея:
https://uploads.disquscdn.com/images/349a8559fd4864a3e440641656bd670d4aff03c1c8c7e8dc5de3ec93d5e79d56.png
Лично мне как простому пользователю почитать это все конечно интересно, но не более… Я все «камни кидать» буду в владельца программы, а далее это уж его забота реагировать на это или нет, и если реагировать, то как… Отвечать за прогу должен тот кто имеет с нее профит, остальные — это просто участники процесса…..
В идеале, за конечный продукт отвечают все члены команды. Владелец продукта (проджект овнер а агиле) может и не понимать всех тонкостей. По тому задача разработчиков и тестеров подсказать ему что не сработает, что лучше изменить, а что целесообразно улучшить.
важно отметить что невозможно создать всеобъемлющий набор тестов. Поэтому ошибки могут годами быть незамеченными.
Это не ошибка. Если смотреть так, то «ошибку», надо заменить на «некорректное поведение». Которое может быть как следствие ошибки, так и последствия работы в Неожиданных ситуациях.
Если разработчик функции, для тех данных которые он предполагал или разумно должен был предположить (покрыто тестами), написал правильную функцию, она безошибочна. Даже если потом появились иные данные, в которых она глючит.
Это тезис из фундаментальной книги Майерса «Надежность программного обеспечения». Тагда почти все сводилось к вычислительным задачам. Представьте программу решения квадратного уравнения. На входе — его коэффициенты, на выходе — корни. Внутри алгоритм ветвится в зависимости от набора коэффициентов. Перебрать все значения невозможно. Возможно в какой-то ветке запрограммировали неправильно, но она настолько редко встречается, что проскочила мимо тестов.
Нет смысла упираться в конкретную книгу, потому что это происходит везде. В строительстве и машиностроении, в сопромате и теоретической механике. Программирование — не исключение.
Надо разделять ошибку в известном знании и недоработку из-за неизвестного.
Пример. Был некий казус с военным самолетом, который над мертвым морем, получил высоту ниже уровня моря. А была катастрофа ракеты Ариан, куда вкорячили софт от младшей
ошибки имеют разные типы. Тот, о котором я говорил относится к численным методам. Отображений математической модели на ее численную реализацию может быть сотни. Если не очень удачно, то это может вылезти в специфических условиях через много лет и тогда нужно менять реализацию.
спасибо большое за статью, было интересно и знакомо
за фотографии отдельнок спасибо 🙂
Как правильно сказано в начале статьи — все проекты разные. Я лично ни разу не разрабатывал мифическое «простое мобильное приложение», как с этим обстоят дела — не знаю. Но при разработке более-менее крупных проектов всё чуть сложнее (о некоторых вещах уже упомянули в комментариях, я повторюсь для связности изложения):
1. Программисты (по крайней мере, рядовые программисты) почти никогда не определяют архитектуру приложения. Это задача архитектора (product architect, systems architect и т.п.) — только он обладает полным знанием о том, как с технической точки зрения должны стыковаться все части проекта. Эту роль может играть обычный сениор из команды, а для совсем крупного проекта может быть и выделенный человек.
2. Если приложение — часть общего продуктового предложения компании, то очень часто выделяется (в дополнение к архитектору и руководителю проекта) ещё product manager — т.е., управляющий всем жизненным циклом продукта, не только разработкой. Иногда он входит в команду и подчиняется руководителю проекта, чаще — находится снаружи и подчиняется заказчику/спонсору.
3. Программисты очень часто делятся на front-end (клиентская часть, пользовательский интерфейс) и back-end (бизнес-логика, хранение данных, публичные API) — причин тому много, основных две: существенно различные технологии и существенно различные требования к художественному восприятию. Ну и фронты ещё могут делиться по платформам для кросс-платформенных приложений, конечно.
4. На всех крупных проектах есть выделенная группа технических писателей/копирайтеров, которые собственно готовят текстовое наполнение продукта — всякие там туториалы, подсказки, вот всё такое. Ниже в комментариях сказали, что это редкость для мобильных проектов — ну, фиг знает. Даже в небольших проектах такая роль обычно есть, просто потому, что ни один программист, как правило, не способен связно изъясняться ни на одном общеупотребимом языке.
5. Аналогично 4, на всех крупных проектах по крайней мере на аутсорсе есть эксперт по UX — user experience, пользовательский опыт, эргономика пользовательского интерфейса. Иначе бяда-бяда — даже очень талантливый дизайнер зачастую не может учесть все мелкие фишки типа «нажать вот на эту кнопочку одновременно вот с этой будет невозможно на устройствах больше 5 дюймов». Вот и привлекают специально обученных людей со специальным инструментарием, по крайней мере на этапе прототипирования интерфейса.
Вот как-то так.
То, что вы описали — это разработка больших Enterprise-систем, где мобильный клиент — всего лишь один из подпроектов. Но часто все бывает намного проще.
1. Архитектура в мобильных приложениях сильно проще, чем в desktop или backend и она:
— частично описана в best practices компании; нет никакого смысла описывать с нуля;
— частично диктуется используемыми библиотеками/фреймворками.
Так что программистов (обычных мидлов) вполне хватает для нормального качественного продукта.
2. Product Owner в статье описан. Называть можно по-разному, суть не изменится. Конечно, может быть больше одного человека, если у вас всего лишь подпроект большого проекта.
3. Я не хотел вылезать за рамки мобильной разработки. Поэтому намеренно оставил backend в стороне (тем более, что очень часто его не включают явно в проект мобильного приложения — считается, что это отдельно уже сделано, а если что не так, пишите в тех.поддержку серверной стороны).
4. Для Enterprise — безусловно есть команда технических писателей. Для мобильного B2C — далеко не всегда. Насчет того, что ни один программист не способен изъясняться — спасибо, посмеялся. Из самой крутой команды тех.писов, что я когда-либо видел (у них реально почти все прямые конкуренты в РФ тупо копипастили), половина — выходцы из программистов. Это вообще вопрос обучения и требований — я всегда своих программистов заставлял писать так, чтобы тех.писам можно было использовать написанное только дополняя, а не переписывая с нуля.
5. Единственный раз когда я видел изнутри серьезный мобильный Enterprise, дизайн полностью был выдан заказчиком, поэтому не знаю, кто и как этим занимался. А в B2C все же обычно ищут дизайнера с навыками UX.
Ну да, я и сказал, что чисто мобильные приложения не разрабатывал, поделился опытом Enterprise-разработок. С техническими писателями — let’s agree to disagree, я лично пока не встретил программиста, который бы мог коротко, понятно и без 20 грамматических ошибок на лист написать инструкцию по использованию приложения (я лично, скажем, пишу понятно и относительно грамотно — но получается очень многословно, не умею компактно формулировать мысли); также не встречал программистов, которые бы смогли, например, аккуратно пройдя по интерфейсу подобрать последовательные формулировки подсказок, обеспечить единообразное использование терминов и т.п. (это работа, конечно, не только техписов — тут участвуют и ПМ, и ПА, и дизайнеры, и даже legal); вообще такого рода проблемы на стыке естественного и гуманитарного, на мой взгляд, настоящие программисты решают плохо, да. Ну, может мне так не везло, конечно…
Добавлю две копейки:
1. Именно по тому, что часто в проектах средней руки и ниже нет UX дизайнера (или вообще сотрудников знакомых с UX на достаточном уровне), мы и получаем миллионы приложений (сайтов и т.д.) которыми не удобно пользоваться.
2. Если говорить о совсем маленьких проектах (в том числе — стартапах), то иногда в 1 человеке могут объединяться сразу Бизнес аналитик, Project Manager, Product Owner/Product Manager. В клинических случаях он может еще выступать еще и в роли UX analytic.
Работа мечты — быть тестировщиком новых игр и получать за это деньги))
Есть и другие мечты — получать деньги не работая)))
Это кажется так первые пару дней. Потом — довольно скучная и занудная работа, совершенно никакой романтики. И, как с любой тестировкой, с кучей пинков со всех сторон.
Калькуляторы должен тестировать Эльдар…у него это хорошо получается)
Как объяснить, что например программа была отличной, а потом вышла версия №2 и пошли отзывы — не работает, галиматьё, отписываюсь…?
Заказчик? Экономия на программистах? Тестировщиках?
>> не работает
Экономия на бюджете (программистах, тестировщиках), либо на сроках (часто можно сделать продукт быстрее, но с понижением качества).
>> галиматьё, отписываюсь
Это вообще ни о чем.
Почему ни о чём? Полно вижу отзывов, когда скачал программу и работал с ней, потом она обновилась и понеслось. То вход не входишь, то вылетает, то не те данные или с опозданием показывает — заходишь в отзывы и там у людей и написано- зачем мол программа обновилась? Если старая версия пахала и пахала. Часто такое случается с мобильными версиями сайтов новостей и т.п. Для примера: Сайт калужского перекрёстка — кп40.
>> Почему ни о чём?
Потому что непонятно, что именно не понравилось. Особенно «отписываюсь». Подробности нужны
>> То вход не входишь, то вылетает, то не те данные или с опозданием показывает
Вот это уже нормальное описание проблем и с ним можно обсуждать, почему так получилось. А то ведь бывает, что вроде и работает все, не глючит, но просто стало неудобно пользоваться — и там совсем другие причины.
Я бы на месте автора, не имеющего абсолютно никакого представления о серьезной профессиональной разработке программного обеспечения, не рискнул бы соваться в такую тему.
Пишите потихонечку за MIUI да сяёми, лучше получается. ))
>> Я бы на месте автора, не имеющего абсолютно никакого представления о серьезной профессиональной разработке программного обеспечения, не рискнул бы соваться в такую тему.
Я стесняюсь спросить, где вы успели ознакомиться с моим резюме? И тем более позвонить в компании и уточнить, что я там на самом деле делал и на каком уровне.
А где можно? Я насчет резюме.
Может действительно есть о чем поговорить?
Ну, т.е. вы не видели, но утверждаете. ОК. Боюсь, что в этом случае говорить просто не о чем.
Вообще-то я не утверждаю. Просто, на мой взгляд, ролевая «начинка» проекта зависит от самого проекта. Если это мобильное приложение, то все примерно так и есть, как Вы описываете. А если на стапелях полновесная многопользовательская система с многопроцессорной резервируемой логикой, СУБД, коммуникационными серверами и т.д. …. Ролей больше. Включая даже такие, какзалось бы, совсем не «софтовые» вещи, как правовое обеспечение, экономика, планирование… К сожалению, когда в работе проект, в котором предполагается 200-300 тысяч строк кода, все совсем не так. Вот поэтому я (возможно, сдуру 🙂 ) зацепился за громкое название статьи. А на поверку что?
«… приложение под Android или iOS».
Уже и не рад, что ввязался. 🙂
P.S. А предложение насчет пообсуждать «то, о чем» остаетсяв силе.
>> Если это мобильное приложение, то все примерно так и есть, как Вы описываете.
Тогда непонятно, о чем вообще речь. Естественно на android-mobile-review я пишу о мобильной индустрии в том или ином проявлении (продукты, технологии, процессы и так далее).
>> А если на стапелях полновесная многопользовательская система с многопроцессорной резервируемой логикой, СУБД, коммуникационными серверами и т.д. …. Ролей больше.
Разумеется. Но вот только нет никакого смысла писать сюда про суровый Enterprise. Есть гораздо более подходящие площадки.
>> А предложение насчет пообсуждать «то, о чем» остаетсяв силе.
Если на тему Enterprise, то я пас. Устал уже от этого, оттого и ушел в mobile.
«… ушел в mobile…»
надеюсь только для передохнуть. нет? )))
Пока назад не собираюсь 🙂
С чегой-то вдруг такие суровые утверждения? Видел парочку проектов и там было по-другому? А если бы видел парочку десятков проектов по всему миру, может в 1-2 было бы именно так.
А если не пару? И не только в России-матушке? И не только видел, а и башкой отвечал за запуск и вывод на боевой режим? ))