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

Для нас техническое задание — это обширный свод документов, описывающий все, что необходимо для достижения желаемого результата клиентом. Исходя из ТЗ, дизайнеры понимают, что необходимо изобразить и как пользователь будет этим пользоваться. Разработчики узнают, какие данные будут приниматься, храниться и обрабатываться в продукте.
Но есть еще один момент, который стоит объяснить. ТЗ — это способ зафиксировать объем работ. Именно то, что написано в ТЗ, будет реализовано в проекте — ни больше, ни меньше. Всегда есть возможность подписать дополнительное соглашение к договору и оценить объем работ исходя из новых данных.
В нашей работе мы постоянно сталкиваемся с одним и тем же моментом: в начале работы заказчик общими словами объясняет, что он хочет получить. Как бы мы ни старались уточнить детали, полного понимания достичь не удается, так как зачастую никто не знает, как именно должно работать приложение, пока не появится первый прототип. Разочарование наступает, когда заказчик получает не то, что ожидал, хотя все выполнено согласно ТЗ. Поэтому ТЗ постоянно дорабатывается и изменяется после каждого разговора с заказчиком и результатов использования продукта.
ТЗ — это не панацея от всех проблем. Но этот документ, будучи формализованной договоренностью, спасает много нервов и предотвращает ненужные конфликты с клиентом. Мы всегда работаем с ТЗ. Если у клиента нет такого документа, мы начинаем его писать, так как по-другому ничего хорошего не получится. И да, ТЗ стоит денег и времени, но это окупается прогнозируемым результатом работы множества специалистов.
Пишите свои мысли по этому поводу в комментариях — мне будет интересно узнать ваше мнение. Если вам нужно написать ТЗ или вы не знаете, с чего начать, пишите нам. Наша команда будет рада вам помочь. До скорой встречи.

Что такое Scrum и Kanban?

Всех приветствую! Много работаем с кодом, команда уже не маленькая. И вот мы приходим к тому, что надо как-то с этой командой работать. Заказчик намерен внести какие-то изменения по ходу процесса, т.к. после нашей демонстрации оказалось, что мы не учли один нюанс в его работе. И этот нюанс отбросил нас на неделю переработки БД, кода и документации. 😭

Как жить команде разработки в условиях такой неопределенности и постоянных изменений?

Есть несколько методологий разработки программных продуктов: Waterfall, agile, спиральная и прочие. В своей повседневной работе мы используем agile, т.к. нам постоянно приходится работать с изменениями в ТЗ.

Мы пишем код, создаем БД, верстаем интерфейсы. Затем тестируем все получившееся, чтобы оно работало как мы планировали, соответствовало ТЗ, было удобно в использовании и не падало от неожиданного ввода от пользователя.

Затем документируем наш код, иначе спустя неделю никто и не вспомнит, какой параметр зачем нужен.

Каждую пятницу мы показываем результаты нашей работы за неделю клиенту и даем ему возможность попользоваться всем этим добром.

После чего получаем обратную связь. Не всегда приятную, но, по нашему опыту, всегда полезную.

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

И так по кругу, пока не получится то, что надо.

В целом, в таком круговороте нам больше всего подходит Scrum.

Основные компоненты этой методологии следующие:
Роли: Scrum Master, Product Owner, Development Team.
События: Sprint Planning, Daily Stand-up, Sprint Review, Sprint Retrospective.
Артефакты: Product Backlog, Sprint Backlog, Increment.


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

Немного расскажу, как у нас работает Scrum.

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

Далее постановка задач на следующий спринт (у нас это 1 неделя). Задачи выбираются из специального, приоритизированного списка задач — Backlog’a. Задачи распределяются на команду разработки.

Далее команда сама разбирается, кто и что будет из этого делать: кто-то силен в базах данных и backend, кто-то берет на себя frontend-разработку.

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

Очень важно выбрать подходящую методологию для вашего проекта. Не все проекты и команды могут нормально принимать изменения в середине работы. Есть проекты, где требуется точное соответствие ТЗ. Тогда Scrum тут будет неуместен. Работаем по Waterfall.

Надеюсь, это было интересно. Пишите комментарии, подписывайтесь на нас в соц. сетях и до скорой встречи.

Сегодня поговорим о категориях программного обеспечения. Существует множество классификаций, и одна из них говорит нам, что ПО можно разделить на три большие категории:

🔹Системное ПО,
🔹Прикладное ПО (пользовательское),
🔹Системы программирования.

К системному ПО можно отнести различные драйверы устройств и утилиты, обеспечивающие работу системы.

Системы программирования — это IDE, компиляторы, сборщики проектов, интерпретаторы для разных языков программирования, которых очень и очень много.

Прикладное ПО позволяет решать пользовательские задачи, не прибегая к программированию. Это и наши любимые Word и Excel, компьютерные игры и графические редакторы, музыкальные и видеоплееры.

Мы работаем над прикладным ПО. Основная специализация — это разработка веб-сервисов для автоматизации бизнес-процессов на производстве. Работают такие сервисы как через интернет, так и внутри закрытых контуров на предприятии — здесь все на усмотрение заказчика. Для работы нужен только браузер.

Для разработки мы используем несколько языков программирования: PHP, JavaScript. Т.к. проекты большие и сложные, то для ускорения работы мы используем фреймворки, которые уже обладают отточенными и протестированными функциями. В нашем стеке используются Laravel и Vue.js.

Из систем программирования наша команда использует PhpStorm и VS Code, интерпретаторы PHP и Node.js.

Кроме всего прочего, конечно, не обходится без СУБД. У нас в ходу PostgreSQL и MySQL.

Надеюсь, это было полезно. Пишите комментарии — буду рад обратной связи. До скорой встречи.

Что такое SDLC простыми словами?
Software Development Life Cycle — Жизненный цикл разработки программного обеспечения. Это специальный фреймворк для организации процесса разработки ПО.

Хотите сделать качественный и востребованный продукт? Вам точно нужен четкий план, как это сделать. Иначе есть огромный шанс сделать никому не нужную поделку. 😂

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

Для этого мы разработали собственные системы документации для управления любым масштабом разработки.

Хотите покажем как мы работаем? Пишите или звоните все наши контакты для связи в профиле.

Как запустить стартап и не облажаться?

Из всех углов слышу истории успеха очередного технологического стартапа. Молодые и горячие ребята создали нечто невероятное. Привлекли средства инвесторов и набирают друзей к себе в команду и уже ничто не может их остановить.

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

Как же запустить свой продукт и не свернуть разработку в первый же год.

1⃣ Найдите подтверждение что ваша идея идея пользуется спросом
2⃣ Сделайте MVP как можно дешевле и как можно быстрее.
3⃣ Проанализируйте и сделайте выводы о своей аудитории и ее потребностях.
4⃣ Доработайте свой MVP под эти потребности.
5⃣ Повторите с п. 3. =)

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

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

Как придумать бомбический стартап?

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

1. Ставьте опыты над пользователями.
2. Подумали, почему все произошло именно так, а не иначе.
3. Если можно сделать эксперимент без денег, то делаем!

Как сделать эксперимент без разработки читайте в статье

Как довести проект до ума после другой команды?

Возьмем простую задачку довести сайт до ума.

Таких задач на фриланс биржах очень и очень много. Доделать за предыдущим разработчиком, самое неблагодарное из всех вариантов. И мы периодически вляпывались в такие проекты. Посмотрим на это со стороны менеджера проекта. У вас микрокоманда: дизайнер, программист, аналитик, тестировщик. С которыми раньше не работали. И есть бизнес-заказчик, не разбирающийся в тонкостях ИТ-разработки, но что-то уже недовольный. Он этот хоровод оплачивает, если его устроит цена и качество. Первое за что он радеет - это деньги и сроки. Ваши действи?

Правильно: Бежать!

И почему же? Что-то смущает в таком простом деле? Да, и вот что.

1. Запредельная неопределенность
2. Абсолютно не радужная перспектива
3. Неуверенность в команде
4. Непонятки с оплатой
5. Неадекватный заказчик
6. Влезем а потом разберемся…
7. Гарантированный геморрой при негарантированном результате

Картина мира project-менеджера.

Итак, мы по локоть вляпались в задачу “довести сайт до ума”. Как бы я действовал?

1. Надо выяснить почему ушел предыдущий разработчик.
2. Рассказал бы клиенту всю процедуру работы и описал риски.
3. Запланировал время чтобы вникнуть в чужой код. Возможно его придется полностью удалить и все написать заново.
4. Согласовал бы работу в почасовую. Работать с чужим кодом по Fix-price - это самоубийство. В ином случае посоветовал бы закончить проект с предыдущей командой
5. Провел бы Code-review и вычитал документацию, если она есть.
6. Принял бы решение, можно ли работать с текущим кодом или нужно все сжечь и делать с нуля.

Это лишь первые шаги. Если есть желание почитать все 37 шагов, то welcome в статью!

Система автоматизации на производстве
Компания нашего заказчика занимается производством изделий из металла различной сложности для нефтяной и газовой отрасли.

Запросом было:
✅ Создать систему, прозрачную для исполнителей и руководителей, в которой был бы процесс производства, задачи для исполнителей по технологической карте.
✅ Документация для аудиторов. Чтобы по каждой заготовке и изделию можно было посмотреть, кто, когда и что делал с этим изделием.
✅ Уйти от бумажной документации, журналов, актов и перевести всю работу по возможности на планшеты и ноутбуки.
✅ Организовать систему напоминаний и отчетов для руководителей и сотрудников на местах.

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

От чатов к эффективности в ИТ-компании
У нас небольшая команда, примерно 15 человек. Все свои проекты мы ведем в jira. и вот почему:
🔹 jira позволяем работать с задачами по Scrum и Kanban. По спринтам или просто на потоке.
🔹 Позволяет вести Бэклог разработки, фиксировать баги и контролировать выполнение задач.
🔹 Позволяет фиксировать затраченное на задачу время.
🔹 Тесная интеграция с нашими репозиториями на github и gitlab
🔹 Настройка интеграции с CI/CD
🔹 Интеграция с чатом mattermost.
🔹 Интеграция с Confluence для работы с документацией по проекту
🔹 Настроены разные бизнес-процессы для задач разного типа.
🔹 Разделение прав доступа к проектам и задачам на разных стадиях.

Расскажу, как мы внедряли jira в компании в статье ниже.

Legacy-войны: новая надежда
Примерно год назад мы получили в работу проект, разработку которого заказчик начал еще лет 8 назад.

Проект на Yii2 и Vuejs2. За время работы этого сервиса сменилось 4 команды разработки.

В начале разработки проекта все шло неплохо. после смены 2-х команд разработки все пошло не по плану. Сильно просело качество кода, что привело к эффекту снежного кома.

Проблемы начали нарастать. Решать вопросы и внедрять новый функционал становилось все сложнее и требовало больше времени и нервов.

Дальше начинается экшен. Читаем в статье ниже!

🚀 5 ключевых преимуществ автоматизации учета на производстве: Почему нельзя медлить?

Сегодня автоматизация учета на производстве уже не просто тренд, а вынужденная необходимость для любого предприятия. Это единственный способ остаться конкурентоспособным, эффективным и устойчивым в своем развитии. Разработка и внедрение таких системы не терпит отлагательств. Поговорим о преимуществах:

1. Повышение точности и прозрачности учета.
2. Увеличение производительности труда
3. Оптимизация запасов и уменьшение издержек
4. Уровень обслуживания клиентов
5. Контроль и управление производственным процессом.
💬 Подробности в нашей статье.

Если вы спросите разных людей, кто такой PM, то можно получить много разных интересных ответов.

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

Роль PM очень сложна и многогранна. Кроме того, он имеет разные функции в зависимости от компании.

Подробности в статье ниже. Жмите кнопку и узнаете больше о работе Продуктовой команды!.

Мы работаем с заказными проектами, и почему-то заказчик частенько недоволен тем, что долго делаем работы, сделано не то, что нужно и прочее. И как в такой ситуации быть? Разбираемся по порядку.

Начало.
Когда берём проект в работу, идёт достаточно длинный диалог с клиентом, выясняем, что же он хочет сделать, какие вопросы он решает на своем производстве и какие проблемы у него с текущими ИТ-решениями. А вот дальше начинается самое интересное.

Мы приблизительно понимаем как реализовать тот или иной функционал, но как конкретно мы его реализуем, понятия нет ни у кого.

Дизайнер пока не представляет, как это будет выглядеть.

Программист не представляет, какое архитектурное решение будет здесь наиболее уместным и не приведёт к катастрофе в дальнейшем, при доработке системы.

Бизнес-аналитик ещё не знает всех сценариев использования этой системы.

И это ещё не самое интересное! Все происходит как по методичке. Раз за разом ситуация повторяется. Продолжение в статье ниже...

Почему мы решили заниматься разработкой собственного продукта?

На дворе весна 2024 года. Прошло два года со дня основания нашей компании. За это время мы прошли интересный и сложный путь от региональной веб-студии, до разработки собственного ит-продукта.

Первый шаг, разработка сайтов

Решили пойти простым путём, начать с создания сайтов, лендингов и интернет-магазинов. Был период, когда сидели без заказов. Каждый раз было как-то неприятно оттого, что клиенту всегда что-то не нравится. То дизайн, то не так работает, то почему в поиске не появился. И чтобы мы не делали всегда ощущение, что мы виновны во всех проблемах клиента. При этом мы всегда шли на уступки клиенту и доделывали то, что он хочет. Думали, что работаем на «имя». Смею заметить, что клиенты платили от 5000₽-20000₽.

Разочарование

Быстро поняли, что с сайтами не проживёшь. Спустя почти год, с трудом окупали офис. Клиентоориентированность, конечно, важна, но не в ущерб собственному существованию.

Читайте продолжение в статье ниже!