- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Самое простое - ставим сроки завершения проекта, разбиваем на временные промежутки, в которые проверяете сколько сделано.
Народ, надо понимать, что короткий двухнедельный спринт, это та самая минимально-допустимая величина, когда можно создать что-то более-менее законченное. Сверхкороткие релизы (раз в неделю) хорошо подходят только для техподдержки, когда надо фиксить мегатонны мелких багов.
длинные релизы 3-4 недели, имхо, расхолаживают разработчиков, начинается разброд и шатание.
а так да. скрам двухнедельный оптимален.
У нас - Раз в неделю по четвергам разбор полетов ( примерно час ) и каждый день, по утрам на ногах быстрая раздача тасков по исполнителям. (10 минут)
по утрам на ногах быстрая раздача тасков по исполнителям. (10 минут)
У нас 14 человек и в 10 минут не получается уложиться)))
Правильнее - сразу оговаривать сделать то, то и то за столько, столько
Если бы все так было просто))) А когда задачи на аутсорсе а разрабы на окладе? как тогда контролировать?
Мне кажется почасовая оплата это полный нонсенс в такой теме!
Правильнее - сразу оговаривать сделать то, то и то за столько, столько
Почасовая оплата в большинстве случаев является ориентиром для расчёта стоимости работ. Как правило мелких.
Особенно когда нет чёткого ТЗ и допеределки уже выходят за рамки оговоренного бюджета.
Почасовая подходит для офиса, рабочего места, где работник в поле зрения в принципе.
Для удаленки это полный нонсенс!
Всё совсем наоборот. В офисе оплачивается ставка (ака за присутствие на рабочем месте). + возможно % или бонусы за результат.
Фрилансер же меняет свое время (ака кусок жизни) на деньги.
Проще и разумнее - сразу оговаривать задачу и цену.
Проще и разумнее - заказчику написать внятное ТЗ и огласит бюджет. Но это в идеальном мире. На практике это редко.
Вы исходите из того, что есть четкая и детальная формулировка задачи, а не "ичный кабинет пользователя". А так-то да.
С другой стороны, если есть некая устраивающая "скорость разработчика", то можно сэкономить время заказчика (которое скорее всего дороже времени разработчика) и давать менее детально расписанные задачи и не требовать заранее оценку, если конечная цена и результат устраивают.
Так есть у вас чёткие ТЗ или нет лишней писанины? Или что под лишней писаниной понимается?
У меня аллергия на четкие ТЗ
Жизнь это поправит :)
Не думаю. Я не имею дел со строгими заказчиками - вообще :)
Строгий - это когда ты выполнил работу строго по ТЗ - он заплатил строго по договоренности.
Нестрогий - это когда ты колупался неделю, делая неизвестно что - а он посмотрел и сказал: "Э-э-э, братуха, да ты сделал никому не нужную хрень, платить тебе не за что".