• Как оценивать сроки системному аналитику в новом проекте?

    vabka
    @vabka
    Токсичный шарпист
    В первый месяц мне дают задачу и просят дать точную оценку. А я не могу ее дать, потому что:
    1. Я не понимаю еще работу действующих систем;
    2. Я не понимаю какое количество систем нужно будет доработать, чтобы решить задачу;
    3. Я не знаю насколько документация точно соответствует и нужен ли делать реверс-инжиниринг кода

    И таких "не понимаю/не знаю" у меня первые 3-6 месяцев работы очень много

    Если совсем нет инфы, то говори "мне нужно столько-то времени, чтобы дать примерную оценку, напишу позже".

    Если счёт на часы - говори "пару дней".
    Если счёт на дни - говори "неделю или две".
    Если счёт на месяцы - говори "через год/к осени/итд"
    Ибо чем больше срок - тем больше неизвестность. Чем больше неизвестность - тем выше вероятность, что срок будет расти.
    Если задача много времени требует - лучше разделить на несколько более достижимых целей и давать оценку следующей, после выполнения предыдущей.

    К примеру "Сколько времени займёт сделать вот такой продукт?" (на первый взгляд - дофига) - отвечаешь "Proof of concept с вот такими минимальными фичами сделаем через столько-то"
    Ответ написан
    Комментировать
  • Насколько адекватно требовать домашнего развития от разработчиков?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    чтоб работать в лучших компаниях, ты должен сам быть лучшим, в конкурентных условиях когда все динамично развивается - это означает постоянное развитие, обучение, как правило ценой потери взаимоотоношений, семьи, развлечений. Это единственный путь наверх.
    Но можно быть "средним", тогда ничего этого не нужно. Само собой подавляющее большинство компаний посредственные, так же как и кадры которые там работают и это нормально. Не нормально это когда в посредственной компании с кадров спрашивают будто ты в гугле работаешь))))
    Ответ написан
    2 комментария
  • Курсы для junior project manager?

    Vovakorn
    @Vovakorn
    Менеджер с десятилетним стажем в ИТ
    Комментаторы язвят, но можно разобраться во многом самому. Все с чего-то начинают.
    Если есть деньги, можно купить курс у больших онлайн-платформ (скилбокс, нетология, гикбрейнс), но если есть мотивация и время, то можно начать самому.

    Курсы
    • Бесплатный и короткий курс об основах профессии: https://pmclub.pro/courses/pm-101
    • Фундаментальный курс про управление проектами, если пройдёте весь (действительно пройдёте), вы будете не хуже 20-30% рынка управленцев: https://selihovkin.com/p/pmp-exam-prep


    Ютюб:


    Книги:
    1. Борис Вольфсон - “Гибкие методологии разработки”. Комментарий: Кратко и по делу об основных гибких методологиях разработки.
    2. Селиховкин Иван - “Управление ИТ-проектом”. Комментарий: Даёт хорошую теоретическую основу.
    3. Джефф Сазерленд - SCRUM. Революционный метод управления проектами.
    4. Максим Батырев - “45 татуировок менеджера”.
    5. Сарычева, Ильяхов - “Новые правила деловой переписки”.
    6. Борис Спирт - “Отчаянные аккаунт менеджеры” (за исключением части про характеры).
    7. Дэвид Ален - GTD (Getting Things Done). “Как привести дела в порядок”.
    8. C. Дж. Скотт. - “Ноль во Входящих”.
    9. Джим Кэмп - “Сначала скажите нет”.
    10. Гэвин Кеннеди - “Договориться можно обо всем! Как добиваться максимума в любых переговорах.
    11. Том Де Марко - Deadline. Роман об управлении проектами.


    Методологии управления проектами:
    1. SCRUM (Лучше прочитать книгу Сазерленда и методичку Вольфсона выше, но кратко вот)
    2. Канбан (habr)
    3. Waterfall, каскад (wiki, third)


    Технические азы
    • Архитектура Web для начинающих https://tproger.ru/translations/web-architecture-101/
    • Клиент-серверная архитектура (wiki, Link)
    • Как работает браузер (wiki, Link)
    • Что такое веб-сервер (wiki, Link)
    • Frontend/Backend - в чем разница (wiki, tproger)
    • Что такое адаптивная верстка (wiki, Link)
    • Что такое хостинг (Link)
    • Что такое DNS (Link)
    • Что такое виртуальная машина (wiki, Link)
    • Что такое кеш (wiki)
    • Git - что это и зачем (wiki, большая статья)
    • Apache - что это и зачем (wiki)
    • NGINX - что это и зачем (wiki, link)
    • Что такое SSL-сертификат(wiki, link)
    • Зачем нужна сборка (wiki1)
    • Что такое CI (wiki)
    • Что такое b2b и b2c (wik1i, wiki2)
    • Что такое UI и UX(UI, UX, habr)
    • Что такое Mobile First (wiki)


    ---

    Знания сами по себе никому не нужны. Если вы где-то работаете, попробуйте взять на себя доп.работу по ведению проекта, или помогите кому-то в управлении. Это потом можно будет занести в резюме. Главное, чтобы были результаты.
    Ответ написан
    1 комментарий
  • Разработчик недисциплинированно трекает время. Что делать?

    Jeer
    @Jeer
    уверенный пользователь
    Очень много интересного почерпнул в этом треде.
    Казалось бы, автор задаёт один простой вопрос "почему люди не отмечают затраченное время?". И столько пустой болтовни, ненужных советов, не относящихся к этому вопросу. Размусоливаний каких-то ситуаций, которые у них на работе, но, опять же, абсолютно не относящихся к данному вопросу. Или переход к другой теме, например, много было про оценку задач, да, это интересные всё темы, но это опять же не относится к теме данного поста.
    Автор меня приятно удивил, пытаясь вначале отвечать всем и по существу, но уже устал к концу, хотя верные ответы находятся не на самых залайканных ответах.
    Одно время я поработал в компании, где после каждой задачи надо было писать отчёт, прикладывая листинг кода! так как реально вообще другой отдел занимался сдачей отчётности (по списанным часам из таких отчётов выставлялся счёт заказчикам) и они даже не в курсе были, чем занимаются программисты. Большего маразма я в жизни не встречал. И когда я стал работать в других компаниях, где надо просто списать затраченное время, я понял, что это прям намного проще и понимаю, зачем это надо менеджменту.
    Но тут встретил людей, которые этого не понимают. То есть, в текущей конторе не было такого, что надо списывать время. Многие (из старичков) откровенно саботировали этот процесс, сопротивление просто громадное, одно из лидирующих мнений было, примерно, следующее: "я раньше не списывал время и сейчас не собираюсь, потому что мне это не надо". Понятное дело, что в такой ситуации весь менеджмент и планирование в полной жопе. Ну, мне понятно. И тут возникает главная загвоздка и ответ на этот тред. Вам необходимо, во-первых, правильно объяснить, зачем это надо. Во-вторых, сделать учёт времени неотъемлемой частью процесса.
    Аргументов по первому пункту тут уже приводилось много и варианты для конкретного человека могут быть довольно специфичные. Что если сотрудник будет просто списывать время, то уже будет видна его загрузка и можно меньше задач ставить в спринт. Или другой пример, один сотрудник сидит на каком-то проекте и ни холодно ни жарко другим людям списывает он время или нет, но появляется какая-то задача, надо ему сделать апи для другого сотрудника. И эта задача блокирующая, но он её не делает. Отговариваясь на митингах, что занимался другим. "Дружок, я не вижу, чем ты занимаешься, если нет списанного времени, я могу считать, что ты ничем не занимаешься, но при этом блокирующая задача перенесена в другой спринт" - разбор полётов и обоснование для списания времени.
    Есть такой тип людей, где-то тут тоже мелькало "я забиваю на списанное время и в конце недели просто рисую цифры с потолка, чтобы отстали". Такое тоже присутствует. Это низкая культура и низкая дисциплина. И с этим тоже можно работать (это относится ко второму пункту). Так же в этом треде предлогались решения, кто-то сказал, что тимлид сказал списывать время в конце дня, как закончил работать. Ну, запретите на программном уровне списывать время за предыдущие дни. Справедливости ради стоит отметить, что иногда вечером не всегда успеваешь это делать, то есть, можно сделать так, что списывать время можно предыдущий день можно до дейли митинга (до 10 утра, к примеру). Если это не происходит, то в присутствии всей команды уточнять, чем человек занимался вчера и напирать на то, что вместо того, чтобы быстренько занести своё время теперь этот человек крадёт время всей команды.
    Резюмируя, первое, надо доходчиво объяснить, зачем это нужно работнику (не вам, а ему), второе, необходимо сделать списание времени частью рабочего процесса
    Ответ написан
    4 комментария
  • Коммуникация между digital-агентством и заказчиком. Как быть, если заказчик не успевает сделать свою часть проекта к дэдлайну?

    inoise
    @inoise
    Solution Architect, AWS Certified, Serverless
    В любом контракте должны быть прописаны действия при не соблюдении условий любой из сторон. Если такого нет то никто никому на самом деле не должен ничего кроме как закончить работу и оплатить ее
    Ответ написан
    Комментировать
  • Разработчик недисциплинированно трекает время. Что делать?

    @SlimHouse
    Сквозь тернии к звездам
    Пока что пришел к тому, что самое эффективное, хотя и не 100% решение - это настроить трекер таким образом, чтобы при переводе в определенные статусы трекер требовал отметить время.

    Также нужно на стэндапах/митингах/планерках доносить важность этого, если это действительно важно, и напоминать забывающим перед всей командой.

    p.s. был один неизлечимый случай, и этого человека перевел на почасовую оплату (правда были ещё причины для этого). Проблем с трекингом времени теперь нет.
    Ответ написан
    Комментировать
  • Разработчик недисциплинированно трекает время. Что делать?

    @SODINNER
    У нас компания достаточно маленькая, но что сделал мой начальник: Он написал простой сайт, куда мы записываем имя компании и потраченное время + проведённую работу. Выполнил задание - добавил на сайт и клиент получает счёт на эти часы. Оплату мы берём за единицы по 15 минут, то есть 3 часа работы это 12 единиц по определённому прайсу, в данном приложении вписываем собственно кол-во единиц.
    Ну и в принципе всё, тут люди говорят что это всё дело на менеджерах, а не на кодерах и нужно дать причину кодерам трекать своё время, но меня с самого начала приучили делать это и я принял это как должное, как одну из обязанностей работы. Но тут всё таки нужно верить каждому на слово, если есть недоверие - этот метод не подойдет. Но он самый простой и легкий, написать такой сайтик вообще труда не составит.
    Но допустим даже работник чуть приувеличил кол-во часов, вписал вместо 4 часа - 5 часов, это разве страшно? Вы же не платите почасово разработчику деньги за проделанную работу, а наоборот, платят вам клиенты. Как дело они не разбираются и такая практика применяется везде, у кого-то меньше, у кого-то больше, но в основном везде. А так в ИТ очень сложно определённо сказать сколько времени займет та или инная задача, ибо уровень квалификации у каждого человека разный, да и мало ли какое рабочее пространство, то никто не будет спорить 4 там часа или 5 часов надо оплатить. Ну это глупость.
    Всё зависит от вашей компании, у нас работает такой метод и весьма успешно.
    Я лично знаю какой прайс выставляется клиентам и когда проделываю работу на определённое кол-во единиц, сразу понимаю что я как минимум заработал для компании больше, чем мне выплатят за этот день и уже могу спокойно выполнять другие задачи, не загоняя себя.
    Ответ написан
    Комментировать
  • Разработчик недисциплинированно трекает время. Что делать?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если оценка превышает запланированную более на 30 процентов

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

    Как менеджер, вы должны учитывать этот момент, и составлять характеристику на людей, тасовать их в разные команды, назначать им разные задачи (или делегировать микро-таймменеджмент на тимлидов).

    Если же хотите математику - готовьтесь к тому, что у вас будет большая текучка, пока вы не сможете укомплектоваться молодцами, одинаковыми с лица, то есть примерно одинаковыми. Но это займет уйму времени (то есть денег). Собственно одна из работ менеджера состоит в том, чтобы правильно распределиться ресурсами, а это в том числе и людьми.
    Ответ написан
    1 комментарий
  • Разработчик недисциплинированно трекает время. Что делать?

    @strelok011
    Хм. Как же яростно народ отстаивает свое желание не сидеть на поводке :)

    Опишу работу на галерах:
    есть счетчик типа апворка (их хватает), трекает время с скриншотами. Разработчик меняет таски в трекере,
    каждые 2 часа меняет мемо (комментарий в трекере), в трелло/жире меняет активную таску по мере выполнения. Одновременно в работе не более одной, внутри таски чекпойнты, требуемые для реализации для более четкого понимания.
    Работа по аджайлу, скрам. Требуется планирование задач на спринт, примерная оценка в часах или условных единицах. Спринт - неделя или две. Каждый день стендап на 5 мин по итогам предыдущего дня и планинг следующего.
    Каждый вечер письменный отчет о выполненных задачах и план на следующий день.
    Менеджер проекта следит за прогрессом, если просадка по скорости - вовремя обращает на это внимание, с командой пробует найти решение проблемы либо оповестить заказчика о возникших трудностях.
    Оплата - зарплата фикс за работу из расчета 8ч в день по счетчику. Овертаймы - отдельная такса.

    Для чего - контора работает на выполнение заказной разработки. Предварительно идет оценка трудоемкости, исходя из планируемых часов выкатывается стоимость заказчику. Соответственно - контроль использованного на задачи времени важен и нужен для оценки менеджером и бухгалтерией - идет работа по плану или начинаем работать в убыток.
    Эффективность методики - контора за 5 лет попала в топ 50 рейтинга ИТ по РФ, постоянный рост как проектов так и штата.
    Работа не простая, либо становишься эффективным специалистом, либо гуляешь.

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

    Жесткий контроль процессов, результативности труда. Приветствуется рост знаний, проекты самые разнообразные.

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

    Тут пишут 'успел в дедлайн' и прочую чепуху. Вопрос - кто устанавливает дедлайн в ваших конторах? Аджайл подразумевает самоуправление команд разработчиков. Цифры берутся не с потолка. Методики позволяют оценить скорость работы команды, на ретро делают обзор прошедших спринтов, найти решение каких либо проблем, выяснить, успеваем или нет. Все давно придумано, бери и пользуйся.
    Если сотрудник не видит необходимости в отчетности, ему не важно, придет ли следующий заказчик, работает на отвали - что он тогда тут делает? Отчетность важна для прогнозируемого результата. Для нормальной работы необходимо сформулировать базовые ценности компании, которые ей позволят выжить и быть эффективной. Нет цели - четыре негра станцуют заупокой.
    Ответ написан
  • Разработчик недисциплинированно трекает время. Что делать?

    Как человек, постоянно забывающий логировать время в джире или делающий это задним числом и от фонаря, могу назвать следующии причины:
    - не вижу смысла, ни разу не разбирали сколько был эстимейт и сколько заняло, а больше применения найти не могу
    - достоверно это делать сложно, сложно даже достоверно статус задач поддерживать, (собственно на него и ориентируюсь, заполняя задним числом, но иногда откровенная лажа получается и тогда просто "рисуешь" правдоподобную картину)
    - джира неудобный инструмент для этого, удобного вообще не нашёл

    Советы, если это вам реально надо:
    - автоматизируйте максимально, лучше всего ориентируясь на статусы задач в джире, обеспечив их достоверность (не допускать отсутствие активных задач, не допускать несколько активных задач одновременно, не допускать работу над "чужими" задачами и т. п.). Можно какого-то чат бота завести, который раз в час будет спрашивать "над какой задачей работаешь? "
    - не просто объясните зачем это вам надо, а регулярно показывайте, что вы это используете для заявленных целей и заявленную пользу приносит, например на дэйли митингах разбирайте сколько часов команда отработала за прошедший день и выявляйте причины отклонений от плана
    Ответ написан
    6 комментариев
  • Разработчик недисциплинированно трекает время. Что делать?

    @dplsoft
    вы, если вы хороший менеджер, вы должны, наверное, понимать, что недоверие и чрезмерный контроль - становятся слишком накладными в плане трудозатрат. почитайте почему в китае работает практика "ту-ань-ши" кажется, когда в громадной компании всего 3 уроня управления - и у каждого менеджера по 40 замов, и почему этого нет в американо-европейской практике, где 1-2-3 зама - это "норма", и в итоге управленческий аппарат раздувается на множество слоев.

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

    и будьте готовы к появлению графы в трудозатратах "заполнял журнал трудозатрат, 1 час в день".
    более того, вы должны эту графу предложить. как минимум потому, что хороший руководитель проекта всегда выделяет в wbs отдельную графу работ под разванием "управление проектом". и в вашем случае, заполнение детальных отчетов о затратах на задачи - это как раз "управленческие расходы".

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

    вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
    почему вас не устраивает скажем 10% погрешность в этих значениях?

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

    и более того - это как раз и есть ваша работа как менеджера - следить за этим.
    если бы все люди сами все делали автоматически и честно - тот же фрилансер всегда сам правдиво, точно и по расписанию все заполнял - вы стали бы ненужной прослойкой.
    Ответ написан
    1 комментарий
  • Разработчик недисциплинированно трекает время. Что делать?

    @0x131315
    Оценивает задачу тот, кто будет её выполнять, с запасом, как ему комфортно, менеджер дополнительно прибавляет процент на риски (исходя из истории и опыта), и резервирует время и бюджет у заказчика.
    Если не получается, чтобы задачу взял тот, кто оценил, тогда особенно важно, чтобы оценка была с запасом. Особенно если задача ушла неопытному разработчику - он её может выполнять вдвое-втрое дольше.

    Разработчики записывают всё время по задаче, как им удобно, в свободной форме, но с привязкой к задаче. Это может быть непосредственно разработка, поддержка, аналитика, консультации - любая полезная деятельность должна быть оплачена.
    Записывают как и когда им удобно, но заранее предупреждаются о сроке закрытия спринта/сделки, чтобы успели проставить время.
    От закрытого времени напрямую зависит их (и не только их) доход, так что если что-то не записали - значит работали бесплатно, мотивация трекать более часто. Опять же нужна прозрачность, чтобы разработчики понимали, что от их записей зависит и их доход и фирмы.

    Систем трекинга много, всяких.
    Но это разработчики - так что в ходу много кастомных, внутренних, даже частных трекеров, которые сливают записи по api в кастомный корпоративный трекер.
    Есть всевозможные клиенты для корпоративного трекера, в т.ч. веб-морда и mobile apps. Разрабатываем сами, кому как удобно, что-то приживается, что-то отмирает - живая экосистема.
    Корпоративный трекер в свою очередь можно синхронизировать с редмайнами. Некоторые клиенты умеют заливать и в трекер и в редмайны, т.к. хранят данные в универсальном формате.

    Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
    В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
    Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
    Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
    Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
    А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
    В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.

    Плюсы подхода: почти всегда укладываемся в бюджет, часто обходимся дешевле договоренностей, хорошие отношения с заказчиками.
    Минус подобного подхода - приходится часть бюджета резервировать на риски, эта часть бюджета замораживается на два спринта, и может быть влита в 3й.
    Как итог заказчику приходится закладывать бюджет чуть больше необходимого, но за счёт этого получаем намного более предсказуемое и стабильное планирование, к тому же в большинстве случаев этот небольшой переизбыток бюджета остаётся неиспользованным, и в среднем это бесплатно: то, что заморожено в текущем спринте, будет разморожено в следующем, и через спринт может быть пущено в дело.
    Ответ написан
    2 комментария
  • Разработчик недисциплинированно трекает время. Что делать?

    @AMenschikov
    Такая же проблема была, но тимлид контролировал и спрашивал ежедневно и все привыкли. Мы это не из за дисциплины делаем, а для улучшения планирования, корректировки коэффициентов и подсчёта стоимостей фичей, ну и непродуктивные задачи типа митингов режем
    Ответ написан
    Комментировать
  • Как спасти разработчика от выгорания? И стоит ли спасать?

    @dmshar
    Очень интересный кейс. И не простой.
    Но, во-первых, что-то у вас не так в организации проекта, если любой может лЁгко снести свой код за два дня до дедлайна. А где копии, а где контроль удаления?
    Есть над чем поработать даже без относительно к ситуации, которую мы рассматриваем.

    Во-вторых, проблема "выгорания" - это проблема психологии. Мне такие проблемы при удаленной работе попадались один раз. И честно говоря, даже при офисной работе с ними справиться не легко - но тут как-бы человек на виду, всегда можно поговорить на диванчике, за чашкой кофе. А на удаленке контакт значительно слабее, поэтому надо сказать , что и шансы на успех будут на порядок ниже.
    Вы должны вообще-то говоря понять, что как только вы - как работодатель и как исполнитель - приняли решение об удаленной работе - все личные проблемы исполнителя остаются вне поля вашего внимания. Вы должны его об этом поставить в известность сразу-же. Это его плата, которую он несет в обмен на удобства его работы дома. Он должен понимать, что это не он, это вы согласились на то, что-бы он не тратил время-деньги на дорогу, на присутсвие в офисе, на завязывание галстука и шнурков на ботинках, на жесткий контроль часов и т.д. "Выгорел" - это не COVID-19 подхватил, не ногу сломал, упав с дивана и не кошка любимая заболела, срочно надо к ветеринару. "Выгорел? - ну пойди соберись и работай дальше. Не можешь - поезжай на Бали, расслабся, как вернешся - подавай резюме на свободную к тому моменту вакансию, тогда и будем решать". Тем более, что участник проекта из новых, а с новыми - всегда легче прощаться, чем с теми, с кем ты сделал десяток проектов. И после десятого совместного проекта я бы "выгорел" - еще потерпел-бы, дав человеку передышку. А если это начинается на втором-третьем месяце первого проекта?

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

    Пока писал - понял, что на самом деле тут таки таки два разных решения.

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

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

    Ну вот как-то так.
    Удачи вам в решении проблемы.
    Ответ написан
    1 комментарий
  • Выбор платежной системы для мультиязычного приложения?

    @boss_lexa
    Для старта

    В росcии есть системы которые сплитуют платежи и сами выплачивает исполнителям и площадке - но они работает только по России. Зарубежные не будут работать с российской компанием. Поэтому для старта - проще принимать платежи на свою компанию, и отдельно выплаты делать.

    Выплаты
    ип на усн 6% + агентский договор с исполнителями
    выплаты по России нормально получится сделать только юрлицам (через обычные платежки) - по таким получится платить налогн только 6% с размера вашей агентской комисии. те если покупатель платить 1000 руб, площадка получает 200 руб, и 800 руб исполнитель - то ваш налог 6% от 200 руб = 12 руб налог.
    Выплаты физлицам и зарубежным исполнителям - вы для налоговой нормально не обоснуете (тк будете их переводить как попало) - поэтому 6% платите со всей суммы, те 6% от 1000 = 60 руб налог.

    Физлицам в РФ можно выплачивать через яндекс кассу на счета/карты/кошельки

    Другим зарубежным контрагентам нормальных платежек нет, через банк там swift комиссия от 30$ (еще и банки корреспонденты откусывают сверху) - малые суммы невыгдно отправлять, поэтому юзаем любые доступные способы:
    • привязываем личные мультивалютные карты тинькоф к paypal и делаем выплаты на paypal
    • просим выставить счет через payoneer и оплачиваем его личной картой
    • paysend - переводу на карту/счет оплачиваем его личной картой
    • просим выставить счет через payoneer и оплачиваем его картой
    • western union - в отделение или на счет
    • money gram
    • сбербанк переводы на европейские счета в евро
    • сбербанк переводы на на зарубежные карты в евро/долларах


    Во всех личных переводах везде есть лимиты, сильно много не получится перевести.

    Прием платежей (все платежи принимаете на свою компанию):
    • яндекс касса: карты + apple pay + google pay + кошельки (только рубли)
    • paypal (20+ валют)
    • альфабанк: карты + apple pay + google pay (30+ валют)


    В яндекс кассе и альфабанке обязательно просите менеджера чтобы открыл все нужные вам страны для приема карт - иначе не пройдут платежи. После того как поработаете какое-то время подайте заявку на возможность отключения 3DS для ряда стран очень помогает (сразу не дают отключить тк им нужна положительная платежная история без chargebackов)

    Для нормальной работы:
    Регистрируете LLC в США
    открываете счет в США на компанию
    подключаете stripe и paypal для приема платежей
    для выплат - просите чтобы исполнители зарегались в payoneer и дали вам их реквизиты виртуальных счетов в США. и выплачиваете им деньги через интернет-банк, а когда обороты подрастут сделаете договор с payonеer - они вам дадут api для выплат, будете слать через банк один платеж им и выплачивать исполнителям на их аккаунты payoneer
    Ответ написан
    Комментировать
  • Как можно подтвердить номер телефона кроме СМС?

    @orbit070
    А что вы собрались подтверждать пушем, устройство?)
    Смысл СМС в том что подтверждается принадлежность номера телефона человеку, а пуш высылается на устройство, то есть пушем вы лишь подтвердите что тот кто пытается зарегистрироваться с этого телефона делает это с этого телефона)
    Более дешёвые варианты это подтверждение регистрации по звонку - либо отвечаете на звонок и вам диктуют код, либо вам звонят со специального номера, четыре последние цифры которого и есть тот самый код, который нужно ввести

    Например вот
    Ответ написан
    2 комментария
  • Прототипы и UX/UI для менеджера проекта. С чего начать?

    mixail_fet
    @mixail_fet
    Дизайнер веб-интерфейсов
    Смотря что закладывается в понятие "прототипирование интерфейсов", если черно-белый набросок, то да - Axure RP.

    Что касается UX/UI, рекомендую почитать книги, которые подойдут для менеджера проектов:

    Майк Монтейро «Дизайн — это работа» - поможет грамотно презентовать дизайн проекты и научится руководить дизайнерами.
    Психбольница в руках пациентов - Купер - подтянет навыки UX-проектирования, в основном увидите в ней проблемы из прошлого и как их можно решить. Очень будет полезно прочитать менеджеру проекта.
    Не заставляйте меня думать - Алан Купер - просто библия, для всех кто связан с интерфейсами.

    Эти три не больших книги, введут вас в курс дела и научат мыслить по другому, в области UX.
    Ответ написан
    Комментировать
  • Retrofit правильно как авторизоваться в header?

    @fuliozor
    Web and Android developer
    Можно токен передать таким образом:

    @GET("/api/v1/datasets")
     Call<List<PostModel>> getData(@Query("id")int count, @Query("name") String resourceName, @Header("Authorization") String token);
    Ответ написан
    Комментировать
  • Как выполняется форматирование номеров телефона в Андроиде?

    akaish
    @akaish
    Стек Java\Android
    Если хотите форматирование, как в системном приложении "контакты" - просто посмотрите, как это сделано в исходниках этого самого приложения.
    Ссылка на git с исходниками
    Ответ написан
    Комментировать
  • Доступ к телефонной книге в Андроиде. С чего начать?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    С чтения документации
    Cursor cursor = contentResolver.query(CallLog.Calls.CONTENT_URI,
        new String [] {Calls._ID, Calls.NUMBER, Calls.DURATION, Calls.TYPE},
        null, null, Calls.DATE + " DESC ");
    Ответ написан
    Комментировать