Тим

Изучайте техники оценки. Их в интернете много.
Другое дело, что прибавлять в сухую процент к оценке это бандитские методы. Так можно работать только с "колхозниками" которые в IT и в разработке не смыслят.

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

Пользовался маком 4 месяца. Все это время промучался с поиском аналога. В основном либое 300-400 долларов говно похожее на проджект, либо дешевая фигня с багами и резаным функционалом. В итоге аналог не нашел. Работал с проджектом через разные виртуальные машины с виндой. Но это всё неудобно и не всегда работает стабильно.

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

Странные какие то вопросы. Необходимо обсудить регламент работы менеджера и регламент проекта. Определить точки отчетности менеджера перед вами, и пускай работает. По результатам отчетов будет понятно когда наступают риски и стоит ли вмешатся. Всё ведь просто и очевидно.

Это же основный принцип менеджмента - спланировать, контролировать. Вот и спланируйте работу менеджера.

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

Не ищите других вариантов. JIRA - всё что вам нужно. Главное не разорится на аддонах из магазина атлассиан. И не наставить кучу хлама, т.к. начинает дико лагать. (Agile в JIRA очень жрет ресурсы)

Не видел, что бы фрилансеры работали на крупных проектах и были там ключевыми персонами. Конечно неприятно работать в вонючем офисе на маленьких проектах с низкими ставками, но это же и во фрилансе будет если у вас вонючая квартира с бабушками\мамами, детьми и дешевые заказчики.

Всё в сравнении...

Текущие офисы солидных компаний могут заменить только идеально отстроеные дома с личными офисами и терасами. Иначе от лукавого. Офис имеет больше преимуществ нежели дом.

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

В ТЗ вообще не должно быть скриншотов. Максимум - блок схемы.
Скриншоты и картинки это не ТЗ, это уже ФЗ - Функциональное задание. Не путайте!

Если в ТЗ вставлять скриншоты то ТЗ по более-менее среднему проекту будет состоять из 100-150 листов, что есть абсурдом. В ТЗ должны быть прописаны требования. По которым затем напишется методика испытаний для сдачи проекта и отдельно функциональные задания на то или иное требование или печень требований.

ТЗ должно быть лёгким для контроля изменений. Если для внесения изменения вам надо будет менять скриншоты или переписывать целую главу, то вас ожидает каторга и страдание. Я придерживаюсь не более 30 страниц в ТЗ.

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

В конце написания, форматирую, перемещаю текст по доке для красоты. Когда пишу тз, то пишу просто по порядку без структуры. Потом отдаю на тестирование разработчику и тестировщику. Они комментируют ТЗ задавая вопросы что где не понятно, или предлагают свой вариант описания если я написал недоступно\неправильно. Потом комбинирую правки и отдаю руководству. Руководство добавляет свои 5 копеек и можно показывать клиенту. (постоянный показ клиенту проходит по мере написания ТЗ, что бы не оказалось, что вы писали 2 недели чепуху которая клиенту не нужна).

Начинал с дна. Сначала дизайнил, потом стало интересно верстать то что надизайнил, затем кодить, затем проектировать, затем аналитика, и всё это на базовом уровне. Затем пошел аналитиком, и за 4 месяца взял маленький проект под хорошие заслуги. и так разрослось как то до крупных проектов в год.

Google Docs + Axure RP 7.
Сделал, залил, кинул ссылку, получил фидбек, поправил, кинул ссылку и так до финиша.
Затем можно гугл доку экспортнуть в каноничный Word, а из Axure нарезать скриншотов для мокапов в таски или картинок в ТЗ.

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

А чем не подходит Metro рабочий стол?

Вопрос довольно каверзный, так как имеет несколько путей решения.
1) Можно сместить сроки (Они смещаются даже на самых дорогих и страшных проектах где казалось нельзя ничего сместить. Нужно лишь правильно аргументировать...);
2) Можно посадить помощь в пару (Ваш "запоздалец" будет излагать задачи и будет подсказывать по архитекутуре и логике проекта, а "новый" свежим взглядом окажет помощь. Помогает всегда, вопрос лишь в реалиях уложится конкретно в 1 день, если там трудозатрат на 3 дня. Тут уже надо подключать больше людей. Лишь бы хватило компетенции поделить задачу на это количество людей)
3) Упростить задачу (наверное, самое простое и применяемое на практике решение. Если по бизнесу задача критична, то её можно довыписать в доделку. Важно уловить на чем разработчик завис и постаратся эту сложность срезать но обеспечив задаче "сдачу" по требованию хотя бы в минимально подобном виде)
4) Перенести дедлайн (дедлайн он чем то обусловлен. релиз, показ, тест, либо же стопер для другой задачи. ну если речь про джуна, то необходимо избегать поручения зависимых задач на джунов. ну а если отойти от уровня и говорить о дедлайне, то можно исключить задачу из релиза или показа. Частенько такое практикуется. Ни кто пока от сотрудничества не отказался. Чаще всего на сдаче крупных годичных проектов у нас 5-15% требований не сделаны к релизу до конца и в него не включены. Да, кланяемся, извиняемся, работаем ночами но это все равно решение лучшее когда другое уже не поможет)

Грамотный менеджер должен понимать, что любой ресурс это ресурс. Важно лишь его правильно использовать. Если ваш джуниор жрет за мидла а далает как недоджуниор, то это не повод его выганять из команды, это повод платить ему соответствующие деньги.

Ресурс должен работать! Каким бы галимым он не был. Если издержки перевешивают профит от ресурса, то да, следует выгнать. Чаще всего, издержки мизерные. Нужно лишь правильно это построить.

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

С некоторыми даже происходили невероятные метаморфозы из-за этого. Кто то перестал курить по 15 раз на день бегая на балконы с кофе. Кто то перестал читать ленты вконтакте и лайкать смешные видео. И не пришлось никого наказывать или ставить жуткие правила в офисе. Сверхурочная работа выбила дурь из людей и они ходят с 9 до 18 что бы делать работу не показывая головы из неё пока не сделают.

У Air низкого качества дисплей. Особенно по запасу яркости. Летом работать в ярких офисах - невозможно. Приходится искать место потемнее, чего нельзя сказать про Retina у PRO. А если захочется поработать на свежем воздухе то тем более. Дисплей у ейра - ужас.

Вы говорите 2 мало, я скажу - 4 тоже мало. Учитывая, что софт в прогрессии жрет память, еще через год и 8 будет мало. Сейчас уже каждая вторая вкладка в хроме съедает до 50 мб памяти.

Hearthstone не проблема. Будете яйца жарить на алюминии через 15 минут харстоуна. (любой игры или фотошопа с двумя десятками слоев)

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

Когда при проектировании у человека уходит час на форму авторизации и он думает и ищет примеры как расположить Remember me, и подписать ли её Remember, или Remember me или Remember login и т.д., то это уже проблема.

В первую очередь, нужно быть опытным пользователем который видел всё. Тогда в выборе элемента интерфейса и его положения проблем не будет.

Для вдохновления листаю bootsnipp.com и https://dribbble.com/

Полтора года сидел на Axure. Аналогов для себя еще не нашел. Но параллельно использую Balsamiq.
Для себя определился, Axure - если надо выйти на уровень понимания, и продемонстрировать, что-то в динамике, изменяющееся; Balsamiq - если надо, банально, зарисовать эскиз("мокап") страницы и впихнуть в ТЗ либо передать дизайнеру.

Если затрагивать вопрос удобства, то предпочитаю Balsamiq. Я все мокапы рисую сразу под фреймворк Twitter bootstrap, а в бальзамике это проще всего. Там и иконки есть, и цвета быстро подбираются похожие и элементов достаточно. В акшуре приходится подольше помучатся. Особенно с таблицами и иконками.

Там где в бальзамике я для какого то таска эскиз зарисовую за 5-10 минут, в акшуре надо минут 20 повозится. И еще мусорно выглядит.

Confluence WIKI. Стоит у нас в довесок к Atlassian JIRA.
В ней все требования удобно связываются якорями на другие документы где описаны фичи. И желательно делать сноски с номером таска в Jira. На вопрос стоит ли? Да стоит. Легче контролировать приёмку и разработку. Хотя отдельно по приемке нужно делать ПМИ тестирование.

При этом WIKI красиво умеет увдомлять о измении на странице. Если что то мажорное, то все учстники на почту получают красивое уведомление с подчеркнутым текстом добавленного. Очень удобно, должен я отметить.

Одно дело нарисовать интерфейс, другое дело потом его обвесить фичами. На опыте часто встречал моменты, когда процесс отрисовки макетов был между аналитиком и клиентом лично. А затем макет поступал в работу. И печаль начиналась тогда, когда клиент уже обрадовался, что будет определенный контрол или элемент интерфейса на макете а разработчик когда увидел макет то сказал "вы афигели. что это вообще такое? где вы это нашли. вот вам радиобатоны и все".

Поэтому, мой процесс проектирования интерфейсов следующий:
1. Зарисовать идею
2. Выцепить какого то мидла в теме по проекту, показать и переделать 20%
3. Показать фронтенд разработчику, передвинуть по другому
4. Показать клиенту

Если менеджер делает 2,3,4 пункт то она делает всё правильно. Если же процесс идет от 1 к 4 проходя 2,3 то это ошибка. А кто там спрашивает, это уже вопрос договорённости в коллективе. И как раз менеджер должен инициировать обсуждения о договорённости о фидбеке внутри команды. Все важные процессы должны иметь фидбек заинтерисованным лицам внутри или за пределами команды. Коммуникации на плечах менеджера.