They say, that experience is something you don't get until just after you need it.
This is especially true in the field of Software Development. You may learn something from a blogpost, a book, a presentation, or even by talking to a Domain Expert, but you have to get your hands dirty in order to fully understand a concept.
Couple of days ago, we have released version 6.0 of XTRF platform - a very first system that enables almost full automation of translation project management.
The platform contains Smart Projects module in version 1.0, which I was developing for the last two years. In this module, we heavily used all the concepts that I was writing about on this blog for couple of years - Domain-Driven Design, Command Query Responsibility Segregation, and Event Sourcing of course - and it is written in Scala.
The platform itself is not new - it was able to manage translation management projects before - even automate some pieces of work, but it was hard to use and, after all, not good enough for the market.
In order to expand the market and gain new customers for the XTRF company, the platform required something more - something easier and more efficient to use. They decided to rewrite the heart of the platform - the project management part - the Core Domain.
I was leading this project from the very beginning. Back then, I had my team of highly skilled developers and a UX designer, who was outlining the vision of what we were building.
The real Core Domain in that field is making automated decisions for translation project manager - so that she does not have to do anything, except for monitoring the progress.
It took me some time to come up with this conclusion, but, as Alberto Brandolini stated once:
"Software development is a learning process. Working code is a side effect".
So, the learning process took place and the side effect has been officially released.
Spread the word!
This is especially true in the field of Software Development. You may learn something from a blogpost, a book, a presentation, or even by talking to a Domain Expert, but you have to get your hands dirty in order to fully understand a concept.
Enter Smart Projects 1.0
Couple of days ago, we have released version 6.0 of XTRF platform - a very first system that enables almost full automation of translation project management.
The platform contains Smart Projects module in version 1.0, which I was developing for the last two years. In this module, we heavily used all the concepts that I was writing about on this blog for couple of years - Domain-Driven Design, Command Query Responsibility Segregation, and Event Sourcing of course - and it is written in Scala.
In order to expand the market and gain new customers for the XTRF company, the platform required something more - something easier and more efficient to use. They decided to rewrite the heart of the platform - the project management part - the Core Domain.
Long story short
I was leading this project from the very beginning. Back then, I had my team of highly skilled developers and a UX designer, who was outlining the vision of what we were building.
At that time, I was thinking that translation project management domain could not be that hard, and this one team was able to provide production-ready, and what was more important - market-ready solution, in couple of months.
Now, two years later, with peak of 7 development teams and 3 UX designers involved simultaneously in the project, I am much more realistic.
Now I know, that at the very beginning I was right - the domain of translation project management itself was not that hard. The thing I did not realize back then - it was not the Core Domain...
Managing translation project is rather simple - you have to find vendors that will translate source files, then you have to arrange schedule, dispatch files, and fill out finances. Additionally, it almost always involves integration with third-party software: Computer-Assisted Translation tools - aka. CAT tools.
Of course, you can manage all of that without specialized software - with little help of Google Spreadsheets for instance. The only problem is that in this case you have to do everything manually - keeping information about your vendors, sending files and instructions via email, taking care of maintaining translation quality and deadlines by calling vendors by phone, etc.
To make your life simpler, couple of years ago, XTRF provided a platform to perform all of those tasks in one single system. Much faster and with better results.
But there was still a lot of work that had to be done by translation Project Manager. Things like searching for vendors, scheduling dates of projects, and others.
The real game-changer in translation project management domain is automation. I realized that about year ago, after I had crunched enough domain knowledge.
Translation Projects
Managing translation project is rather simple - you have to find vendors that will translate source files, then you have to arrange schedule, dispatch files, and fill out finances. Additionally, it almost always involves integration with third-party software: Computer-Assisted Translation tools - aka. CAT tools.
Of course, you can manage all of that without specialized software - with little help of Google Spreadsheets for instance. The only problem is that in this case you have to do everything manually - keeping information about your vendors, sending files and instructions via email, taking care of maintaining translation quality and deadlines by calling vendors by phone, etc.
To make your life simpler, couple of years ago, XTRF provided a platform to perform all of those tasks in one single system. Much faster and with better results.
But there was still a lot of work that had to be done by translation Project Manager. Things like searching for vendors, scheduling dates of projects, and others.
The real Core Domain
The real game-changer in translation project management domain is automation. I realized that about year ago, after I had crunched enough domain knowledge.
The real Core Domain in that field is making automated decisions for translation project manager - so that she does not have to do anything, except for monitoring the progress.
It took me some time to come up with this conclusion, but, as Alberto Brandolini stated once:
"Software development is a learning process. Working code is a side effect".
So, the learning process took place and the side effect has been officially released.
Spread the word!
Interesting post, and good to see you writing again!
ReplyDelete> so that she does not have to do anything, except for monitoring the progress
Could you elaborate on that, e.g. give a specific example? Unless that's a trade secret ;)
For example I wonder how can you automatically ensure the translation quality or manage deadlines with vendors, is that by e.g. setting automated reminders for vendors and other people, and updating progress when a monitored piece of work is finished?
Hi Weronika, thanks for the comment and sorry for the late response. ;)
DeleteIn some ways, the localization business is similar to the software business. People make mistakes, so the Translator needs Proofreader (just like we need code review). Automation makes sure, that valid Proofreader will get valid input from valid Translator - so that Project Manager does not have to do it manually. This is more important in bigger projects with many languages and many people with many skills involved.
Also finances for the project can be automatically calculated based on many factors, like previous notes of given Translator. Project Manager just have to check if everything looks OK.
Translators work with different tools, so the system has to be able to automatically send and receive data from them, so that everybody is up to date all the time.
The goal is to minimize all the repetitive Project Manager's work, so that she can be more productive doing more valuable thigs and maintaining the pace.
Does that answer your question? :)
This comment has been removed by the author.
ReplyDelete